Chuyển đến nội dung
Diễn đàn CADViet
ssg

LandCadViet Utility

Các bài được khuyến nghị

Kà kà, theo tôi nhận định là giữa SSG và Tnmtpc đang không hiểu nhau rồi. SSG thì cần 1 vài mẫu file chuẩn trong khi tnmtpc thì lại đưa ra một số mẫu file tạm hiểu là không "chuẩn" cho LCV. Mấy file ví dụ mẫu của tmntpc thì file *.Dat và file *.ASC là file " chuẩn theo yêu cầu LCV" còn file *.IDX là file được "trút" ra từ một máy đo đạc điện tử và chưa được xử lý nên file này cần phải được "chuẩn hoá" trước khi đưa vào LCV để processing. Việc này thì ta sẽ bàn sau, nghĩa là sau này sẽ làm 1 modul để xử lý cái file *.IDX đó (cái này thì tuỳ thuộc vào máy đo đạc của hãng nào). Tôi cũng có nhiều mẫu file không chuẩn như kiểu file *.IDX mà trứoc giờ khi pót lên có mấy khi mình đề cập đến đâu mà chỉ đề cập đến mẫu chuẩn thôi mà ! Giải thích thế nào nhỉ ?

 

Raw_data ==> Processing1 ==> input_LCVU_data ==> Processing2 ==> Output

 

Thôi tạm thời ta chỉ bàn luận đến cái phần in đậm đã. Còn cái phần in nghiêng chắc chắn phải làm 1 modul để đưa mấy cái mẫu đo từ máy điện từ về mẫu chuẩn rồi !

 

Mong rằng các bạn sẽ hiểu ý tôi vì tôi cũng vấp phải vấn đề này y như SSG hiện đang còn băn khoăn.

 

Đúng đó Ssg Text Tendiem nên luôn luôn đưa vào vị trí Point đề phòng cho mọi trường hợp.

1) Không hẳn vậy, ssg cần tất cả, raw lẫn fine! Mục đích: có được cái "tầm nhìn chiến lược" cho toàn bộ dự án. Lý do: ssg không phải là dân Surveying.

2) Về vị trí ghi các text, lại không thống nhất rồi! Theo bạn, ghi như thế nào là hợp lý, vẹn cả đôi đường? Lưu ý: ssg có thể điều khiển ghi text chính xác ở tất cả các dạng justify, chính xác vị trí dấu chấm thập phân cho text Caodo, muốn thế nào cũng được. Vấn đề quan trọng là ghi như thế nào để các công đoạn sau: nối điểm, tạo thửa... nhận diện được chúng chính xác 100% trong mọi tình huống? Tốt nhất, bạn post 1 file *.dwg lên, nêu 1 ví dụ ghi các text theo ý bạn thật chuẩn vào.

Chia sẻ bài đăng này


Liên kết tới bài đăng
Chia sẻ trên các trang web khác
Kà kà, theo tôi nhận định là giữa SSG và Tnmtpc đang không hiểu nhau rồi. SSG thì cần 1 vài mẫu file chuẩn trong khi tnmtpc thì lại đưa ra một số mẫu file tạm hiểu là không "chuẩn" cho LCV. Mấy file ví dụ mẫu của tmntpc thì file *.Dat và file *.ASC là file " chuẩn theo yêu cầu LCV" còn file *.IDX là file được "trút" ra từ một máy đo đạc điện tử và chưa được xử lý nên file này cần phải được "chuẩn hoá" trước khi đưa vào LCV để processing. Việc này thì ta sẽ bàn sau, nghĩa là sau này sẽ làm 1 modul để xử lý cái file *.IDX đó (cái này thì tuỳ thuộc vào máy đo đạc của hãng nào). Tôi cũng có nhiều mẫu file không chuẩn như kiểu file *.IDX mà trứoc giờ khi pót lên có mấy khi mình đề cập đến đâu mà chỉ đề cập đến mẫu chuẩn thôi mà ! Giải thích thế nào nhỉ ?

 

Raw_data ==> Processing1 ==> input_LCVU_data ==> Processing2 ==> Output

 

Thôi tạm thời ta chỉ bàn luận đến cái phần in đậm đã. Còn cái phần in nghiêng chắc chắn phải làm 1 modul để đưa mấy cái mẫu đo từ máy điện từ về mẫu chuẩn rồi !

 

Mong rằng các bạn sẽ hiểu ý tôi vì tôi cũng vấp phải vấn đề này y như SSG hiện đang còn băn khoăn.

 

Đúng đó Ssg Text Tendiem nên luôn luôn đưa vào vị trí Point đề phòng cho mọi trường hợp.

Đúng đúng, như mình đã nói ở trên, anh nào muốn chơi LandCadViet Utility thì phải xử lý file dữ liệu thành dạng chuẩn để giao tiếp, bỡi vì file dữ liệu có hai loại:thô và tinh, SSg yêu cầu các bạn gửi nhiều loại file để có khái niệm cụ thể hơn, may mà mình không gửi loại file số liệu thô đo bằng kinh vĩ đọc ba dâyvà góc, thì SSg tẩu hỏa nhập ma ngay, có lẽ bạn (và các bác trắc địa nói chung) nên phát biểu mạnh đi chớ, chỉ ý kiến riêng tớ thì có "cá nhân "không? Riêng ý kiến của bạn về text tên điểm luôn đưa vào vị trí point , mình "lăn tăn" lắm, nó phải nằm ở phía trên của point chớ, còn ngay tại point là text cao độ. Thống nhất phương án là chỉ nghiên cứu phạm vi từ "dữ liệu tinh" trở về sau, còn từ thô sang tinh chưa đề cập trong thời gian này

Chia sẻ bài đăng này


Liên kết tới bài đăng
Chia sẻ trên các trang web khác
1) Không hẳn vậy, ssg cần tất cả, raw lẫn fine! Mục đích: có được cái "tầm nhìn chiến lược" cho toàn bộ dự án. Lý do: ssg không phải là dân Surveying.

2) Về vị trí ghi các text, lại không thống nhất rồi! Theo bạn, ghi như thế nào là hợp lý, vẹn cả đôi đường? Lưu ý: ssg có thể điều khiển ghi text chính xác ở tất cả các dạng justify, chính xác vị trí dấu chấm thập phân cho text Caodo, muốn thế nào cũng được. Vấn đề quan trọng là ghi như thế nào để các công đoạn sau: nối điểm, tạo thửa... nhận diện được chúng chính xác 100% trong mọi tình huống? Tốt nhất, bạn post 1 file *.dwg lên, nêu 1 ví dụ ghi các text theo ý bạn thật chuẩn vào.

 

1. elle sẽ lục lại và sẽ post lên cho ssg mấy mẫu đó, cái này đơn giản thôi

 

2. Thực ra elle nhìn file vẽ mẫu của tnmtpc thì thấy cũng không có sao đâu. Bản vẽ giữa mỗi cơ quan có thể khác biệt nhau về cách thức nhưng elle đều xử lý được. Có điều riêng mục bắn số liệu điểm vào CAD thì ta không nên tách ra thành 2 mảng là địa chính và địa hình. chuyện địa chính hay địa hình chỉ mang tính chất quy phạm khi trình bày bản đồ, còn số liệu đưa từ vao máy đo điện tử là đều như nhau, có nghĩa là giá trị đo được bao giờ cũng có các giá trị tendiem, X, Y, H (hoặc code, ghi chú). Tuy nhiên elle là người có quan điểm của người đo, người vẽ, người lập trình (vì đều từng làm ở những vị trí đó) thì thấy chuyện người đo thao tác máy ngoài hiện trường mà nhập code, ghi chú trên máy đo là rất lâu công (đơn giản vì bàn phím máy đo có vài nút chứ không có đủ 101 key như trên keyboard). Một ngày tổ đo của elle có thể đo được 10.000 điểm mà.

 

Còn chuyện text tendiem nên để ở vị trí point là vì khi trong cad user mà dùng lệnh List cái toạ độ text Tendiem ra thì nó phải trùng khớp với toạ độ của point và nó phải khớp với tọa độ cực trong sổ lưu tính toán X,Y; text cao độ cũng vậy. Khi bị mất sổ lưu thì có thể out_put toàn bộ toạ độ cũng như tên điểm, độ cao để in lại sổ sách. Điều này thì SSG đã làm rồi, chỉ việc đặt text Tendiem đúng vị trí point là được còn justify ở đâu để cho dễ nhìn thôi.

 

Đây là mấy mẫu file của elle làm, khá đơn giản vì khi vẽ bản đồ địa chính đặc biệt trong khu đô thị dân cư tỷ lệ 1/200 hoặc 1/500 thì mật độ điểm đo là rất dày do quy phạm quy định. Nếu để đủ thứ lên màn hình cad mà bố trí như của tnmtpc thì chắc loà mắt không thể nối vẽ nổi.

 

http://www.cadviet.com/upfiles/Vidu.zip

 

3. Đó là chưa bàn đến chuyện user nhập số liệu, nếu số liệu được trút ra từ máy đo điện tử thì form data rất đồng đều còn nhập tay mà làm theo mẫu sau thì user rất dễ nhầm lẫn:

1,2323231.505,567345.725,8.176

2,2323233.909,567346.431,8.006

3,2323229.684,567344.761,7.889

4,2323227.315,567347.709,8.030

5,2323222.540,567348.424,8.112

6,2323224.761,567350.175,8.199

7,2323200.161,567319.317,7.747

8,2323181.022,567406.544,7.942

9,2323198.115,567329.033,7.632

 

còn để số liệu dạng như mẫu file CANHNGANG.XYH elle post sau đây thì đỡ nhầm lẫn hơn vì giữa các field elle để space "thoải mái và đủ rộng" để nhìn rõ sự phân cách các filed.

 

để mẫu data như vậy SSG sẽ thắc mắc, ông elle đưa mẫu data thế thì sẽ nhận dạng thứ tự các filed data thế nào, sao mà lắm dấu space và dấu Tab thế, mà vị trí các space lẫn Tab lại lung tung hết cả lên ???

elle giải quyết điều đó như sau (xin đưa một vd chỉ mang tính giải thuật vì elle viết trên Delphi):

 

While not eof(In_file) do begin      // Thực hiện vòng lặp từ đầu file đến cuối file số liệu;
  Readln(In_file, S);                    // Đọc từng dòng số liệu và gán giá trị đọc được vào biến S : String;
  i := WordCount(S, ' ');              // WordCount(S:string; WordDelims : charset) : Integer;  Đếm số field và gán cho biến i
  if i < 4 then THONG_BAO_LOI
  else begin
                                                         ;;///ExtractWord(N : Integer; s:string; WordDelims:charset) : String;
     Tendiem := ExtractWord(1, S, ' ');   // Gán field 1 cho biến tên điểm;
              sX := ExtractWord(2, S, ' ');
              sY := ExtractWord(3, S, ' ');
              sH := ExtractWord(4, S, ' ');
       Val(sX, X, err_code);                   //  Convert to X, Y, H Real type;
       Val(sY, Y, err_code);       
       Val(sH, H, err_code);       
  end;  //if;
  BAN_DIEM;   
end;  //while;

 

tất nhiên còn có mấy function fải đưa vào: WordCount, ExtractWord, BAN_DIEM...

:bigsmile:

Chia sẻ bài đăng này


Liên kết tới bài đăng
Chia sẻ trên các trang web khác
1. elle sẽ lục lại và sẽ post lên cho ssg mấy mẫu đó, cái này đơn giản thôi

 

2. Thực ra elle nhìn file vẽ mẫu của tnmtpc thì thấy cũng không có sao đâu. Bản vẽ giữa mỗi cơ quan có thể khác biệt nhau về cách thức nhưng elle đều xử lý được. Có điều riêng mục bắn số liệu điểm vào CAD thì ta không nên tách ra thành 2 mảng là địa chính và địa hình. chuyện địa chính hay địa hình chỉ mang tính chất quy phạm khi trình bày bản đồ, còn số liệu đưa từ vao máy đo điện tử là đều như nhau, có nghĩa là giá trị đo được bao giờ cũng có các giá trị tendiem, X, Y, H (hoặc code, ghi chú). Tuy nhiên elle là người có quan điểm của người đo, người vẽ, người lập trình (vì đều từng làm ở những vị trí đó) thì thấy chuyện người đo thao tác máy ngoài hiện trường mà nhập code, ghi chú trên máy đo là rất lâu công (đơn giản vì bàn phím máy đo có vài nút chứ không có đủ 101 key như trên keyboard). Một ngày tổ đo của elle có thể đo được 10.000 điểm mà.

 

Còn chuyện text tendiem nên để ở vị trí point là vì khi trong cad user mà dùng lệnh List cái toạ độ text Tendiem ra thì nó phải trùng khớp với toạ độ của point và nó phải khớp với tọa độ cực trong sổ lưu tính toán X,Y; text cao độ cũng vậy. Khi bị mất sổ lưu thì có thể out_put toàn bộ toạ độ cũng như tên điểm, độ cao để in lại sổ sách. Điều này thì SSG đã làm rồi, chỉ việc đặt text Tendiem đúng vị trí point là được còn justify ở đâu để cho dễ nhìn thôi.

OK! phải vậy chứ. Thực ra chọn giải pháp bố trí các text là để khi cần xem đầy đủ các thông tin một lúc, tránh nội dung các text đè lên nhau, còn khi in ấn, một số nội dung text phải ẩn đi. Riêng bản vẽ địa hình, text cao độ có dấu chấm thập phân trùng với point là điều cần thiết vì khi xuất ra bản vẽ giấy, giảm bớt các chấm point bản vẽ sẽ "nhẹ" hơn và giúp người đọc bản vẽ "trực quan" hơn về vị trí điểm mia (bản vẽ giấy sau khi in ra còn phải nhân ra nhiều bản, qua vài lần photo, các chấm point có khả năng "biến mất" nhưng text thì vẫn còn, do vậy giải pháp chọn chấm thập phân trùng point cũng là vì lý do này)

Riêng tùy chọn địa chính, địa hình, mình nghĩ vẫn phải tách biệt vì bản vẽ địa chính, tất cả đều đưa về một mặt phẳng, liên quan tính diện tích, do đó point có giá trị Z=0 sẽ dễ xử lý hơn

Chia sẻ bài đăng này


Liên kết tới bài đăng
Chia sẻ trên các trang web khác

Ssg xin được chốt lại mấy vấn đề:

1) Về các file dữ liệu: elle tổng hợp thêm vài dạng nữa post lên. Mục đích như mình đã nói trên, để mở rộng tầm nhìn. Còn để xử các dạng file này thì không có vấn đề gì, miễn là user tuân thủ các quy định nếu muốn chơi với LCV. Mình sẽ viết Help hướng dẫn chi tiết sau.

 

2) Vị trí ghi text:

Dung hoà các ý kiến, theo phương án:

- Text Caodo: dấu chấm thập phân trùng point. Cái này mình thấy hình như đã là quy ước rộng rãi rồi? Còn việc export ngược lại ra file dữ liệu thì elle yên tâm đi, đã điều khiển ghi được thì đương nhiên lấy toạ độ được.

- Text Tendiem: justify Top-Right, bắt vào point

- Text Code: justify Top-Left, bắt vào point

- Text Ghichu: justify Top-Left, nằm kề dưới Code

Cụ thể như bản vẽ này:

http://www.cadviet.com/upfiles/chaythu.zip

 

Thật ra thì về nguyên tắc, cũng có thể cho phép user tuỳ chọn phương án ghi text, nhưng đưa vào thêm sẽ làm chương trình phức tạp hơn. Mặt khác, ý mình vẫn muốn có sự thống nhất, ít ra là trong phạm vi anh em CadViet. Nếu sử dụng thấy không ổn thì có thể bổ sung sau.

 

3) Về độ cao Z:

Đổi tên toggle "Su dung so lieu Z" thành "Tao cac yeu to theo do cao Z". Chương trình sẽ hành xử như sau:

- Trong file dữ liệu, có cái gì thì "chơi" cái nấy (tối thiểu phải có Tendiem, X, Y)

- Mặc định là tất cả các yếu tố đều vẽ theo đúng độ cao Z của point tương ứng

- Nếu bỏ check "Tao cac yeu to theo do cao Z", toàn bộ các yếu tố tạo thành sẽ nằm trong mặt phẳng OXY (Z=0)

 

Nếu không ai phản đối hay có ý gì khác, ssg sẽ hoàn thiện Module 1 của chương trình y như trên.

Chia sẻ bài đăng này


Liên kết tới bài đăng
Chia sẻ trên các trang web khác
Ssg xin được chốt lại mấy vấn đề:

1) Về các file dữ liệu: elle tổng hợp thêm vài dạng nữa post lên. Mục đích như mình đã nói trên, để mở rộng tầm nhìn. Còn để xử các dạng file này thì không có vấn đề gì, miễn là user tuân thủ các quy định nếu muốn chơi với LCV. Mình sẽ viết Help hướng dẫn chi tiết sau.

 

2) Vị trí ghi text:

Dung hoà các ý kiến, theo phương án:

- Text Caodo: dấu chấm thập phân trùng point. Cái này mình thấy hình như đã là quy ước rộng rãi rồi? Còn việc export ngược lại ra file dữ liệu thì elle yên tâm đi, đã điều khiển ghi được thì đương nhiên lấy toạ độ được.

- Text Tendiem: justify Top-Right, bắt vào point

- Text Code: justify Top-Left, bắt vào point

- Text Ghichu: justify Top-Left, nằm kề dưới Code

Cụ thể như bản vẽ này:

http://www.cadviet.com/upfiles/chaythu.zip

 

Thật ra thì về nguyên tắc, cũng có thể cho phép user tuỳ chọn phương án ghi text, nhưng đưa vào thêm sẽ làm chương trình phức tạp hơn. Mặt khác, ý mình vẫn muốn có sự thống nhất, ít ra là trong phạm vi anh em CadViet. Nếu sử dụng thấy không ổn thì có thể bổ sung sau.

 

3) Về độ cao Z:

Đổi tên toggle "Su dung so lieu Z" thành "Tao cac yeu to theo do cao Z". Chương trình sẽ hành xử như sau:

- Trong file dữ liệu, có cái gì thì "chơi" cái nấy (tối thiểu phải có Tendiem, X, Y)

- Mặc định là tất cả các yếu tố đều vẽ theo đúng độ cao Z của point tương ứng

- Nếu bỏ check "Tao cac yeu to theo do cao Z", toàn bộ các yếu tố tạo thành sẽ nằm trong mặt phẳng OXY (Z=0)

 

Nếu không ai phản đối hay có ý gì khác, ssg sẽ hoàn thiện Module 1 của chương trình y như trên.

Tuyệt! Cách bố trí các text khoa học lắm, vậy còn chần chờ gì nữa, hô xung phong!!...

Chia sẻ bài đăng này


Liên kết tới bài đăng
Chia sẻ trên các trang web khác

Còn rất nhiều việc phải làm. Được một đoạn này post lên để các bạn test giùm:

 

http://www.cadviet.com/upfiles/LCV_01_02.zip

 

Có mấy điều cần tham khảo thêm ý kiến các bạn:

1) Minh hoạ kỹ hơn về các việc tiếp theo của dân địa chính. Tốt nhất là lấy ngay kết quả chạy chương trình của LCV để làm ví dụ.

2) Về layer, hiện LCV hành xử như sau: khi cần dùng 1 layer nào đó, nếu trên bản vẽ không có sẵn sẽ tự tạo layer với Ltype continuous và màu White, nhìn có vẻ đơn điệu và không phân biệt rõ ràng. Các bạn có thể đưa ra 1 quy định chuẩn nào đó về Ltype và Color không? Mình biết là Ltype và Color tuỳ mỗi người nhưng chương trình vẫn ưu tiên trước cho thiết lập của user, nếu không có sẽ dùng thiết lập chuẩn của LCV (riêng đoạn Import Data, LCV lấy theo thiết lập layer ví dụ của tnmtpc)

3) Về Logo LCV, không thấy ai post lên, ssg vẽ đại cho có và đã coding cho nó. Có mẫu nào hay hơn chỉ việc thay vào. Các bạn xem file LCV_logo.dwg và sửa theo ý thích.

 

P/S: I'm sorry! Data dạng *.* chưa dùng được.

Chia sẻ bài đăng này


Liên kết tới bài đăng
Chia sẻ trên các trang web khác
Còn rất nhiều việc phải làm. Được một đoạn này post lên để các bạn test giùm:

 

http://www.cadviet.com/upfiles/LCV_01_02.zip

 

Có mấy điều cần tham khảo thêm ý kiến các bạn:

1) Minh hoạ kỹ hơn về các việc tiếp theo của dân địa chính. Tốt nhất là lấy ngay kết quả chạy chương trình của LCV để làm ví dụ.

2) Về layer, hiện LCV hành xử như sau: khi cần dùng 1 layer nào đó, nếu trên bản vẽ không có sẵn sẽ tự tạo layer với Ltype continuous và màu White, nhìn có vẻ đơn điệu và không phân biệt rõ ràng. Các bạn có thể đưa ra 1 quy định chuẩn nào đó về Ltype và Color không? Mình biết là Ltype và Color tuỳ mỗi người nhưng chương trình vẫn ưu tiên trước cho thiết lập của user, nếu không có sẽ dùng thiết lập chuẩn của LCV (riêng đoạn Import Data, LCV lấy theo thiết lập layer ví dụ của tnmtpc)

3) Về Logo LCV, không thấy ai post lên, ssg vẽ đại cho có và đã coding cho nó. Có mẫu nào hay hơn chỉ việc thay vào. Các bạn xem file LCV_logo.dwg và sửa theo ý thích.

 

P/S: I'm sorry! Data dạng *.* chưa dùng được.

chương trình gặp phải rắc rối sau: khi nhập text tên chủ sử dụng trực tiếp trên command line bị lỗi dấu

Đề xuất giải pháp: sau khi nối điểm, tạo tâm thửa, tự động ghi số thửa theo qui luật từ trên xuống dưới, từ trái sang phải-Tự động tính diện tích thửa. Cả hai text trên được cố định theo tâm thửa đã tạo. Text loại đất và text chủ sử dụng do user nhập sau

Về màu sắc không quan trọng, miễn sao nhìn cho "mát mắt" là được

(sự cố chưa rõ nguyên nhân: nếu sử dụng bảng mã unicode, nhập text trên command line có từ "huỳnh" thì Cad tự động thoát, nhưng bảng mã TCVN3 thì không sao)

Chia sẻ bài đăng này


Liên kết tới bài đăng
Chia sẻ trên các trang web khác
chương trình gặp phải rắc rối sau: khi nhập text tên chủ sử dụng trực tiếp trên command line bị lỗi dấu

Đề xuất giải pháp: sau khi nối điểm, tạo tâm thửa, tự động ghi số thửa theo qui luật từ trên xuống dưới, từ trái sang phải-Tự động tính diện tích thửa. Cả hai text trên được cố định theo tâm thửa đã tạo. Text loại đất và text chủ sử dụng do user nhập sau

Về màu sắc không quan trọng, miễn sao nhìn cho "mát mắt" là được

(sự cố chưa rõ nguyên nhân: nếu sử dụng bảng mã unicode, nhập text trên command line có từ "huỳnh" thì Cad tự động thoát, nhưng bảng mã TCVN3 thì không sao)

Dấu tiếng Việt là vấn đề rất phiền toái! Bạn chạy với Cad2007 trở lên chắc chắn không bị lỗi này. Tuy nhiên, quan điểm của LCV là phải chạy được với mọi version Cad từ 2000 trở đi. Lấy thông tin trong dialog sẽ không bị lỗi như trên. Bạn unzip, ghi đè 2 file sau vào thư mục LCV rồi thử lại xem:

 

http://www.cadviet.com/upfiles/LCV_Patch01.zip

 

Nếu bạn cài font hệ thống TCVN thì trong dialog có thể gõ tiếng Việt bình thường:

 

ttt.jpg

 

Nếu không, trong dialog có thể nhiễu nhưng kết quả ghi ra màn hình Cad vẫn đúng.

Số thửa trong dialog tự động tăng 1 đơn vị so với lần nhập trước.

 

Khái niệm tâm thửa đất nên hiểu thế nào? Trọng tâm, tâm hình chữ nhật bao quanh thửa đất (bounding box) hay là 1 điểm áng chừng bằng mắt? Hiện tại, LCV lấy ngay điểm pick của user làm tâm để ghi các thông tin trên.

 

Riêng ý kiến bạn về lấy thửa tự động e rằng không làm được. Sau khi chạy nối điểm, kết quả chỉ có các line rời rạc nối các điểm với nhau, 1 line có thể thuộc 2 thửa khác nhau. Chương trình rất khó nhận biết cái gì là một "thửa" như cách hiểu của con người! Nó chỉ có thể nhận biết nếu user đã tạo nên các "đối tượng thửa" là các region hoặc pline kín. Mà đã mất công như vậy thì không hay hơn cách làm hiện nay. Nhân tiện, mình hỏi thêm: hiện tại, để lấy diện tích thửa, chương trình đã dùng lệnh Boundary để tạo 1 pline kín bao quanh thửa đất, sau đó xoá nó đi. Theo bạn, có cần xoá không? Hay là tạo 1 layer "Boundary" cho nó vào, phòng khi cần lấy thông tin sau này (khi tạo hồ sơ kỹ thuật thửa đất chẳng hạn)?

Chia sẻ bài đăng này


Liên kết tới bài đăng
Chia sẻ trên các trang web khác
Dấu tiếng Việt là vấn đề rất phiền toái! Bạn chạy với Cad2007 trở lên chắc chắn không bị lỗi này. Tuy nhiên, quan điểm của LCV là phải chạy được với mọi version Cad từ 2000 trở đi. Lấy thông tin trong dialog sẽ không bị lỗi như trên. Bạn unzip, ghi đè 2 file sau vào thư mục LCV rồi thử lại xem:

 

http://www.cadviet.com/upfiles/LCV_Patch01.zip

 

Nếu bạn cài font hệ thống TCVN thì trong dialog có thể gõ tiếng Việt bình thường:

 

ttt.jpg

 

Nếu không, trong dialog có thể nhiễu nhưng kết quả ghi ra màn hình Cad vẫn đúng.

Số thửa trong dialog tự động tăng 1 đơn vị so với lần nhập trước.

 

Khái niệm tâm thửa đất nên hiểu thế nào? Trọng tâm, tâm hình chữ nhật bao quanh thửa đất (bounding box) hay là 1 điểm áng chừng bằng mắt? Hiện tại, LCV lấy ngay điểm pick của user làm tâm để ghi các thông tin trên.

 

Riêng ý kiến bạn về lấy thửa tự động e rằng không làm được. Sau khi chạy nối điểm, kết quả chỉ có các line rời rạc nối các điểm với nhau, 1 line có thể thuộc 2 thửa khác nhau. Chương trình rất khó nhận biết cái gì là một "thửa" như cách hiểu của con người! Nó chỉ có thể nhận biết nếu user đã tạo nên các "đối tượng thửa" là các region hoặc pline kín. Mà đã mất công như vậy thì không hay hơn cách làm hiện nay. Nhân tiện, mình hỏi thêm: hiện tại, để lấy diện tích thửa, chương trình đã dùng lệnh Boundary để tạo 1 pline kín bao quanh thửa đất, sau đó xoá nó đi. Theo bạn, có cần xoá không? Hay là tạo 1 layer "Boundary" cho nó vào, phòng khi cần lấy thông tin sau này (khi tạo hồ sơ kỹ thuật thửa đất chẳng hạn)?

Với phương pháp nhập thông tin bán tự động như trên cũng có cái ưu điểm của nó là thửa nào giải quyết dứt điểm thửa đó, đã vậy thì trong hộp thoại nhập thông tin bổ sung thêm một edit box " địa chỉ ". Không cần thiết giữ lại "Boundary", về phương pháp lấy thông tin để tạo hồ sơ kỹ thuật, theo mình thì cách lấy dữ liệu là "coppy các đối trong cữa sổ chọn". Khái niệm tâm thửa ở đây là trọng tâm

Chia sẻ bài đăng này


Liên kết tới bài đăng
Chia sẻ trên các trang web khác
Với phương pháp nhập thông tin bán tự động như trên cũng có cái ưu điểm của nó là thửa nào giải quyết dứt điểm thửa đó, đã vậy thì trong hộp thoại nhập thông tin bổ sung thêm một edit box " địa chỉ ". Không cần thiết giữ lại "Boundary", về phương pháp lấy thông tin để tạo hồ sơ kỹ thuật, theo mình thì cách lấy dữ liệu là "coppy các đối trong cữa sổ chọn". Khái niệm tâm thửa ở đây là trọng tâm

OK, xem như xong đoạn này. Bạn làm giúp cái mà mình đã nói ở bài trên:

 

1) Minh hoạ kỹ hơn về các việc tiếp theo của dân địa chính. Tốt nhất là lấy ngay kết quả chạy chương trình của LCV để làm ví dụ.

Chia sẻ bài đăng này


Liên kết tới bài đăng
Chia sẻ trên các trang web khác
Khái niệm tâm thửa đất nên hiểu thế nào? Trọng tâm, tâm hình chữ nhật bao quanh thửa đất (bounding box) hay là 1 điểm áng chừng bằng mắt? Hiện tại, LCV lấy ngay điểm pick của user làm tâm để ghi các thông tin trên.

 

Riêng ý kiến bạn về lấy thửa tự động e rằng không làm được. Sau khi chạy nối điểm, kết quả chỉ có các line rời rạc nối các điểm với nhau, 1 line có thể thuộc 2 thửa khác nhau. Chương trình rất khó nhận biết cái gì là một "thửa" như cách hiểu của con người! Nó chỉ có thể nhận biết nếu user đã tạo nên các "đối tượng thửa" là các region hoặc pline kín. Mà đã mất công như vậy thì không hay hơn cách làm hiện nay. Nhân tiện, mình hỏi thêm: hiện tại, để lấy diện tích thửa, chương trình đã dùng lệnh Boundary để tạo 1 pline kín bao quanh thửa đất, sau đó xoá nó đi. Theo bạn, có cần xoá không? Hay là tạo 1 layer "Boundary" cho nó vào, phòng khi cần lấy thông tin sau này (khi tạo hồ sơ kỹ thuật thửa đất chẳng hạn)?

 

Tôi chưa kịp test thử nhưng nêu thêm cho SSG nhận xét sau :

1. Tâm thửa - Centroid đặt đúng trọng tâm của "Boundary" mà bạn vừa tạo ra. Cái này thì không bắt buộc nhưng các phần mềm về địa chính hay làm vậy

2. Trong địa hình thì khác chứ địa chính khái niệm thửa là 1 vùng (region) được tạo bởi các Line hoặc Pline kín, nghĩa là không có khái niệm "đường cong" vì vậy ko dùng spline, arc hay cái gì đại loại như vậy.

3. SSg cứ giữ nguyên "Boundary" vừa tạo ra chắc chắn sẽ phải dùng đến khi muốn lập Hồ sơ kỹ thuật thửa đất và dùng để đánh số thửa tự động hoặc xác định Centroid tự động.

 

Theo elle gợi ý thì nên làm thế này :

 

- User pick vào một vùng đóng kín thì SSG tạo ngay ra ở đó 1 Block hay 1 Atribute text như sau

 

$Sothua

---------

231.1

 

- Chương trình thực hiện tạo region kín bằng lệnh BO

 

- Làm thêm 1 menu "gán nhãn số thửa tự động"

 

- Khi user "pick" hết các thửa trên 1 tờ bản đồ thì chỉ việc chạy lệnh tại menu "gán nhãn số thửa tự động" để chương trình tìm toàn bộ các "vùng" hoặc các Block vừa tạo để bắt đầu tìm $Sothua để đánh số thửa (diện tích đã có khi user pick thì để nguyên).

Chia sẻ bài đăng này


Liên kết tới bài đăng
Chia sẻ trên các trang web khác
Với phương pháp nhập thông tin bán tự động như trên cũng có cái ưu điểm của nó là thửa nào giải quyết dứt điểm thửa đó, đã vậy thì trong hộp thoại nhập thông tin bổ sung thêm một edit box " địa chỉ ". Không cần thiết giữ lại "Boundary", về phương pháp lấy thông tin để tạo hồ sơ kỹ thuật, theo mình thì cách lấy dữ liệu là "coppy các đối trong cữa sổ chọn". Khái niệm tâm thửa ở đây là trọng tâm

 

Quay trở lại bài toán trước kia có bạn nào đó trên diễn đàn hỏi và SSG giới thiệu hàm "GetVert", elle đã đề cập đến vấn đề là "Nếu tờ bản đồ có vài trăm thửa" hay nhiều hơn thì việc ngồi Pick từng thửa để tính diện tích và lập Hồ sơ kỹ thuật cho từng thửa đất là không sáng suốt. Pick từng thửa chỉ hợp với việc giải quyết nhỏ lẻ chứ đứng ở góc độ "máy tính" và ngồi coding thì hơi lãng phí.

Trong đo đạc địa chính elle đã từng gặp 1 khu đo khoảng 500ha cần giải phóng mặt bằng để xây dựng khu đô thị mới và có khoảng 3000 thửa thì chắc làm theo phương án này là không khả quan vì rất chậm, hay nhầm lẫn. Phương án là khi CT chạy hỏi "select close polyline" vẫn hay hơn, nghĩa là chọn một tập hợp các thửa để cho CT chạy. Nó tiện vì có thể đánh được số thửa tự động và làm hàng loạt như một "nhà máy sản xuất hồ sơ". Việc tạo một "Close Polyline" hãy để cho user đảm trách, dễ thôi vì những ai làm bản đồ thì hay cài AutoCAD Map chứ ko hay cài AutoCAD và tạo "Close Polyline" chỉ là một việc đơn giản trong tích tắc. AutoCAD Map có hàng loạt cộng cụ có sẳn để làm việc này.

 

Tôi gửi kèm một bản đồ khu đo làm ví dụ. Trong file vẽ bạn hãy bỏ qua các yếu tố ko cần thiết (mấy bác bên thiết kế quy hoạch làm bản vẽ của elle nó nát ra thế đó) chỉ quan tâm đến RG dự án (layer GIOIHANDAT). Tất cả các thửa nằm trong và bị RG cắt qua đều fải tính diện tích để giải phóng MB và lấy diện tích này để làm căn cứ đền bù, phải in ra 1 Hồ sơ kỹ thuật thửa đất như mẫu trước elle gửi lên... Oài má ơi công việc lạp đi lặp lại hơi nhiều...

 

http://www.cadviet.com/upfiles/vd.zip

 

Đôi dòng tâm sự, cũng chỉ mong bác SSg có cái nhìn tổng quan hơn...

Chia sẻ bài đăng này


Liên kết tới bài đăng
Chia sẻ trên các trang web khác
Quay trở lại bài toán trước kia có bạn nào đó trên diễn đàn hỏi và SSG giới thiệu hàm "GetVert", elle đã đề cập đến vấn đề là "Nếu tờ bản đồ có vài trăm thửa" hay nhiều hơn thì việc ngồi Pick từng thửa để tính diện tích và lập Hồ sơ kỹ thuật cho từng thửa đất là không sáng suốt. Pick từng thửa chỉ hợp với việc giải quyết nhỏ lẻ chứ đứng ở góc độ "máy tính" và ngồi coding thì hơi lãng phí.

Trong đo đạc địa chính elle đã từng gặp 1 khu đo khoảng 500ha cần giải phóng mặt bằng để xây dựng khu đô thị mới và có khoảng 3000 thửa thì chắc làm theo phương án này là không khả quan vì rất chậm, hay nhầm lẫn. Phương án là khi CT chạy hỏi "select close polyline" vẫn hay hơn, nghĩa là chọn một tập hợp các thửa để cho CT chạy. Nó tiện vì có thể đánh được số thửa tự động và làm hàng loạt như một "nhà máy sản xuất hồ sơ". Việc tạo một "Close Polyline" hãy để cho user đảm trách, dễ thôi vì những ai làm bản đồ thì hay cài AutoCAD Map chứ ko hay cài AutoCAD và tạo "Close Polyline" chỉ là một việc đơn giản trong tích tắc. AutoCAD Map có hàng loạt cộng cụ có sẳn để làm việc này.

 

Tôi gửi kèm một bản đồ khu đo làm ví dụ. Trong file vẽ bạn hãy bỏ qua các yếu tố ko cần thiết (mấy bác bên thiết kế quy hoạch làm bản vẽ của elle nó nát ra thế đó) chỉ quan tâm đến RG dự án (layer GIOIHANDAT). Tất cả các thửa nằm trong và bị RG cắt qua đều fải tính diện tích để giải phóng MB và lấy diện tích này để làm căn cứ đền bù, phải in ra 1 Hồ sơ kỹ thuật thửa đất như mẫu trước elle gửi lên... Oài má ơi công việc lạp đi lặp lại hơi nhiều...

 

<a href="http://www.cadviet.com/upfiles/vd.zip" target="_blank">http://www.cadviet.com/upfiles/vd.zip</a>

 

Đôi dòng tâm sự, cũng chỉ mong bác SSg có cái nhìn tổng quan hơn...

Ái chà! làm khó cho SSg rồi. Thực hiện được như ý Ell thì chương trình LCV trở thành một "phần mềm chuyên nghiệp", e rằng hơi khó, theo tnmtpc thì LCV là một "tiện ích" hỗ trợ trong CAD, cho nên không dám đòi hỏi cao hơn ở SSg để đáp ứng đầy đủ các công việc của trắc địa nói chung, địa chính nói riêng, do vậy chỉ yêu cầu trong chừng mực nào đó để LCV thực thi, nếu không SSg bị "kiệt xác" đấy. Mong rằng Ell hiểu ý mình

Chia sẻ bài đăng này


Liên kết tới bài đăng
Chia sẻ trên các trang web khác

Không có gì là không làm được cả các bác ạh. Tất cả các dự án tin học không bị chết về KỸ THUẬT mà chỉ bị chết về quan hệ con người thôi. Mình xem yêu cầu của các bác là thuộc về quan hệ con người.

Trước đây khi mình còn viết ct cho bên PV Quy Hoạch, có nhiều anh cứ chơi theo kiểu nói ra vài yêu cầu rùi bảo khi nào làm xong thì nói tiếp. Kiểu này vừa mất thời gian mà chất lượng sản phẩn lại không cao. Chán. Và hầu như là các sp phần mềm viết tại VN, cho người VN dùng và người VN viết đều theo công nghệ đó.

Tụi nước ngoài nó không bao giờ làm thế và nó cũng không cho người VN mình làm thế với những sp do nó đặt hàng. Vậy nên hầu như bọn mình không bao giờ viết lại. Chỉ viết một lần + Fix bug. Thêm nữa thì bổ sung.

Hôm trước mình và bác ssg đưa FreeMind lên là để mọi người đóng góp ý kiến vậy mà hầu như không thấy ai nói gì. Sau khi bác ssg công bố ra một sản phẩm thì các bác góp ý nhiều quá. Chỉ cần các bác chịu khó suy nghĩ đóng góp ý kiến trước khi mọi người làm thì sẽ dễ dàng cho anh em lập trình hơn.

Một sp phần mềm thì chỉ có mức Alpha, Beta sau đó là chính thức. Các bác mà góp ý kiểu này thì chắc là dùng đến hết các ký hiệu luôn quá: Gama, Xichma...

Bác ssg ạh, thấy bác hết lòng anh em thế cũng thấy thương bác mới đưa ra cái FreeMind đó. Mình nghĩ bác nên dừng lại làm rõ yêu cầu trước khi tiếp tục. Cái gì thì không dám chưa về lĩnh vực này thì tự tin là kinh nghiệm nhiều hơn bác. :bigsmile:

  • Vote tăng 1

Chia sẻ bài đăng này


Liên kết tới bài đăng
Chia sẻ trên các trang web khác
Quay trở lại bài toán trước kia có bạn nào đó trên diễn đàn hỏi và SSG giới thiệu hàm "GetVert", elle đã đề cập đến vấn đề là "Nếu tờ bản đồ có vài trăm thửa" hay nhiều hơn thì việc ngồi Pick từng thửa để tính diện tích và lập Hồ sơ kỹ thuật cho từng thửa đất là không sáng suốt. Pick từng thửa chỉ hợp với việc giải quyết nhỏ lẻ chứ đứng ở góc độ "máy tính" và ngồi coding thì hơi lãng phí.

Trong đo đạc địa chính elle đã từng gặp 1 khu đo khoảng 500ha cần giải phóng mặt bằng để xây dựng khu đô thị mới và có khoảng 3000 thửa thì chắc làm theo phương án này là không khả quan vì rất chậm, hay nhầm lẫn. Phương án là khi CT chạy hỏi "select close polyline" vẫn hay hơn, nghĩa là chọn một tập hợp các thửa để cho CT chạy. Nó tiện vì có thể đánh được số thửa tự động và làm hàng loạt như một "nhà máy sản xuất hồ sơ". Việc tạo một "Close Polyline" hãy để cho user đảm trách, dễ thôi vì những ai làm bản đồ thì hay cài AutoCAD Map chứ ko hay cài AutoCAD và tạo "Close Polyline" chỉ là một việc đơn giản trong tích tắc. AutoCAD Map có hàng loạt cộng cụ có sẳn để làm việc này.

 

Tôi gửi kèm một bản đồ khu đo làm ví dụ. Trong file vẽ bạn hãy bỏ qua các yếu tố ko cần thiết (mấy bác bên thiết kế quy hoạch làm bản vẽ của elle nó nát ra thế đó) chỉ quan tâm đến RG dự án (layer GIOIHANDAT). Tất cả các thửa nằm trong và bị RG cắt qua đều fải tính diện tích để giải phóng MB và lấy diện tích này để làm căn cứ đền bù, phải in ra 1 Hồ sơ kỹ thuật thửa đất như mẫu trước elle gửi lên... Oài má ơi công việc lạp đi lặp lại hơi nhiều...

 

http://www.cadviet.com/upfiles/vd.zip

 

Đôi dòng tâm sự, cũng chỉ mong bác SSg có cái nhìn tổng quan hơn...

Cám ơn các ý kiến, và đặc biệt là file vd của bạn. Ssg đã nói từ lâu rồi nhưng hình như các bạn không chú ý lắm. Kiến thức mà ssg đang thiếu chính là cái nhìn tổng quan ấy. File ví dụ người thật việc thật của bạn có tác dụng cực kỳ quan trọng trong việc định hướng để xây dựng chương trình. Nếu định hướng sai lầm ban đầu sẽ dẫn đến việc tốn nhiều công sức nhưng kết quả không đạt được như mong muốn. Với khu đất có 10 thửa và khu đất có 1000 thửa, tư duy lập trình khác nhau rất nhiều!

Với số lượng thửa như ví dụ của bạn, rõ ràng việc pick từng thửa để đánh số là không ổn. Ssg nhất trí với phương án đánh số tự động mà bạn nêu. Nhưng còn mấy điểm chưa rõ:

1) Đánh số theo chiều từ trái qua phải, từ trên xuống dưới thì hiểu rồi. Nhưng căn cứ vào điểm (point) nào, có phải là theo trọng tâm của thửa đất không? Hay là theo điểm cực Tây và cực Bắc của nó? (hình dạng nhiều thửa đất rất phức tạp, không vuông vắn như ô bàn cờ!)

2) Thông tin về Loại đất, Chủ sử dụng và Địa chỉ như tnmtpc nêu thì nhập như thế nào?

3) Hôm nọ hình như các bạn đã thống nhất ý kiến không dùng attribute block mà chỉ nên dùng text thôi?

4) Còn một số câu hỏi "như thế nào" tương tự như trên nữa chưa xuất hiện! Chúng chỉ lộ diện khi ssg coding xong và các bạn dùng thử mới thấy không ổn!

 

Kết luận:

Qua 1 đoạn thử nghiệm đã làm được, các bạn có thể thấy rõ là Lisp có khả năng rất lớn, có thể giúp chúng ta tăng năng suất làm việc lên nhiều lần. Bản thân ssg, tuy khả năng và hiểu biết có hạn, vẫn có thể cụ thể hoá nhiều ý tưởng thành chương trình (chỗ nào bí đã có anh Hoành cũng như cả cộng đồng CadViet)

Tuy nhiên, ssg e rằng sẽ không thể tiếp tục được nữa nếu như chưa hiểu rõ toàn bộ những việc cần làm tiếp theo trong việc xây dựng bản đồ, bản vẽ, file lưu trữ, hồ sơ... (trước mắt là cho mảng địa chính). Các bạn không giúp ssg thông suốt một cách triệt để thì cũng đành bó tay thôi!

 

P/S: Cám ơn vndes! Mình viết xong mấy ý trên mới đọc bài của bạn. Có lẽ bạn là người hiểu rõ nhất cái khó hiện nay của ssg.

Chia sẻ bài đăng này


Liên kết tới bài đăng
Chia sẻ trên các trang web khác
Không có gì là không làm được cả các bác ạh. Tất cả các dự án tin học không bị chết về KỸ THUẬT mà chỉ bị chết về quan hệ con người thôi. Mình xem yêu cầu của các bác là thuộc về quan hệ con người.

Trước đây khi mình còn viết ct cho bên PV Quy Hoạch, có nhiều anh cứ chơi theo kiểu nói ra vài yêu cầu rùi bảo khi nào làm xong thì nói tiếp. Kiểu này vừa mất thời gian mà chất lượng sản phẩn lại không cao. Chán. Và hầu như là các sp phần mềm viết tại VN, cho người VN dùng và người VN viết đều theo công nghệ đó.

Tụi nước ngoài nó không bao giờ làm thế và nó cũng không cho người VN mình làm thế với những sp do nó đặt hàng. Vậy nên hầu như bọn mình không bao giờ viết lại. Chỉ viết một lần + Fix bug. Thêm nữa thì bổ sung.

Hôm trước mình và bác ssg đưa FreeMind lên là để mọi người đóng góp ý kiến vậy mà hầu như không thấy ai nói gì. Sau khi bác ssg công bố ra một sản phẩm thì các bác góp ý nhiều quá. Chỉ cần các bác chịu khó suy nghĩ đóng góp ý kiến trước khi mọi người làm thì sẽ dễ dàng cho anh em lập trình hơn.

Một sp phần mềm thì chỉ có mức Alpha, Beta sau đó là chính thức. Các bác mà góp ý kiểu này thì chắc là dùng đến hết các ký hiệu luôn quá: Gama, Xichma...

Bác ssg ạh, thấy bác hết lòng anh em thế cũng thấy thương bác mới đưa ra cái FreeMind đó. Mình nghĩ bác nên dừng lại làm rõ yêu cầu trước khi tiếp tục. Cái gì thì không dám chưa về lĩnh vực này thì tự tin là kinh nghiệm nhiều hơn bác. :bigsmile:

 

Đấy là cái khó của anh em CadViet vì hầu như mọi người không phải dân làm soft chuyên nghiệp mà chỉ đá bóng trái chân thôi nên tư duy để xây dựng nên 1 soft là chưa được OK lắm. Ở đây rõ ràng LCV thiếu một thiết kế hệ thống để rồi trên hệ thống đã đc xác định cứ thế mà làm. Hơn nữa mọi người hay như bản thân elleHCSC cũng đang cùng nhau học tập cách làm việc theo nhóm mà. Vn...dos sẽ nhận thấy ngay sự khác biệt cơ bản nhất ở LCV là không phải quan hệ một người cần đặt hàng 1 sp cụ thê A nào đó với các yêu cầu B cụ thể rồi thuê hay nhờ người khác viết mà ở đây là cùng "chụm lại" nêu lên các ý tưởng để xây dựng 1 sp. Rất biết là Ssg vất vả vì hầu như đảm trách toàn bộ fần coding nhưng elle nghĩ Ssg có một niềm vui nhất định khi cùng mọi người làm ra 1 sp mà mọi người dùng đc trong khi đó lại không fải lĩnh vực chính mà ssg am hiểu nhất.

:undecided:

Chia sẻ bài đăng này


Liên kết tới bài đăng
Chia sẻ trên các trang web khác
Đấy là cái khó của anh em CadViet vì hầu như mọi người không phải dân làm soft chuyên nghiệp mà chỉ đá bóng trái chân thôi nên tư duy để xây dựng nên 1 soft là chưa được OK lắm. Ở đây rõ ràng LCV thiếu một thiết kế hệ thống để rồi trên hệ thống đã đc xác định cứ thế mà làm. Hơn nữa mọi người hay như bản thân elleHCSC cũng đang cùng nhau học tập cách làm việc theo nhóm mà. Vn...dos sẽ nhận thấy ngay sự khác biệt cơ bản nhất ở LCV là không phải quan hệ một người cần đặt hàng 1 sp cụ thê A nào đó với các yêu cầu B cụ thể rồi thuê hay nhờ người khác viết mà ở đây là cùng "chụm lại" nêu lên các ý tưởng để xây dựng 1 sp. Rất biết là Ssg vất vả vì hầu như đảm trách toàn bộ fần coding nhưng elle nghĩ Ssg có một niềm vui nhất định khi cùng mọi người làm ra 1 sp mà mọi người dùng đc trong khi đó lại không fải lĩnh vực chính mà ssg am hiểu nhất.

:bigsmile:

 

Bác nói thế thì không đúng rồi. Ở đây không phải yêu cầu các bác làm một cái soft (mà cũng chưa gọi được là soft đâu, mới chỉ là app thui). Mà chỉ yêu cầu các bác nói yêu cầu rõ ràng. Các bác là dân trong nghề, nên các bác phải rành hơn bác ssg và rành hơn mình vì mình không làm về XD. Các bác không thể cho rằng cứ làm ra một sản phẩm rồi thiếu đâu sửa đó hoặc sai đâu sửa đó. Cái này gọi là vô trách nhiệm đó.

Bước trước mắt là các bác phải nghĩ cho được mình muốn cái gì, sau đó là những gì có thể phát sinh. Một ngày chưa nghĩ ra thì 1 tuần...

Khi các bác nghĩ xong rùi thì mình có thể giúp các bác về phân tích hệ thống và thiết kế cơ bản - Free.

Các bác an tâm dù Free nhưng mình sẽ vẫn làm tốt vì cái này còn liên quan đến "thương hiệu" của mình nữa.

Hi vọng rằng những sản phẩm có nguồn gốc từ LCV khi được dùng sẽ không bị cho là "Free".

Mà mình nói các bác nghe: trong làm soft thì thời gian coding không quá 30% thời gian của dự án đâu.

Vậy nên các bác đừng đặt nặng vấn đề coding quá

Chia sẻ bài đăng này


Liên kết tới bài đăng
Chia sẻ trên các trang web khác
1) Đánh số theo chiều từ trái qua phải, từ trên xuống dưới thì hiểu rồi. Nhưng căn cứ vào điểm (point) nào, có phải là theo trọng tâm của thửa đất không? Hay là theo điểm cực Tây và cực Bắc của nó? (hình dạng nhiều thửa đất rất phức tạp, không vuông vắn như ô bàn cờ!)

 

Cái này thì ssg căn cứ vào điểm point trọng tâm - Centroid, hình thù thửa phức tạp kệ nó ko sao. elle sẽ giúp ssg giải thuật này kể cả giải thuật xác định Centroid vì elle đã từng làm rồi, khó nhất là elle viết ko phải bằng lisp mà trên delphi để tạo file chạy *.exe nên tất cả các hàm tính đó elle phải "tính bộ" hết chứ ko tận dụng được các hàm của lisp hay Cad.

 

2) Thông tin về Loại đất, Chủ sử dụng và Địa chỉ như tnmtpc nêu thì nhập như thế nào?

 

Lâu công nhất là cái này vì hầu như user phải nhập tay. Cad có làm đc ko thì mình ko rõ vì số liệu này thường hiểu theo kiểu Database để Link (kết nối) với Cad. Drawing thuộc khái niệm "không gian" còn database thuộc khái niệm phi không gian mà. Nếu đưa hết Sothua, DienTich, TenChu, DiaChi, LoaiDat v.v...hiển thị hết trên bản vẽ thì rối lắm, người ta chỉ để SoThua, DienTich, LoaiDat hiện lên trên bản vẽ thôi. Mình cũng chưa nghĩ nên làm thế nào cho tiện đây.

 

3) Hôm nọ hình như các bạn đã thống nhất ý kiến không dùng attribute block mà chỉ nên dùng text thôi?

Dùng Text thôi

  • Vote tăng 1

Chia sẻ bài đăng này


Liên kết tới bài đăng
Chia sẻ trên các trang web khác
Cám ơn các ý kiến, và đặc biệt là file vd của bạn. Ssg đã nói từ lâu rồi nhưng hình như các bạn không chú ý lắm. Kiến thức mà ssg đang thiếu chính là cái nhìn tổng quan ấy. File ví dụ người thật việc thật của bạn có tác dụng cực kỳ quan trọng trong việc định hướng để xây dựng chương trình. Nếu định hướng sai lầm ban đầu sẽ dẫn đến việc tốn nhiều công sức nhưng kết quả không đạt được như mong muốn. Với khu đất có 10 thửa và khu đất có 1000 thửa, tư duy lập trình khác nhau rất nhiều!

Với số lượng thửa như ví dụ của bạn, rõ ràng việc pick từng thửa để đánh số là không ổn. Ssg nhất trí với phương án đánh số tự động mà bạn nêu. Nhưng còn mấy điểm chưa rõ:

1) Đánh số theo chiều từ trái qua phải, từ trên xuống dưới thì hiểu rồi. Nhưng căn cứ vào điểm (point) nào, có phải là theo trọng tâm của thửa đất không? Hay là theo điểm cực Tây và cực Bắc của nó? (hình dạng nhiều thửa đất rất phức tạp, không vuông vắn như ô bàn cờ!)

2) Thông tin về Loại đất, Chủ sử dụng và Địa chỉ như tnmtpc nêu thì nhập như thế nào?

3) Hôm nọ hình như các bạn đã thống nhất ý kiến không dùng attribute block mà chỉ nên dùng text thôi?

4) Còn một số câu hỏi "như thế nào" tương tự như trên nữa chưa xuất hiện! Chúng chỉ lộ diện khi ssg coding xong và các bạn dùng thử mới thấy không ổn!

 

Kết luận:

Qua 1 đoạn thử nghiệm đã làm được, các bạn có thể thấy rõ là Lisp có khả năng rất lớn, có thể giúp chúng ta tăng năng suất làm việc lên nhiều lần. Bản thân ssg, tuy khả năng và hiểu biết có hạn, vẫn có thể cụ thể hoá nhiều ý tưởng thành chương trình (chỗ nào bí đã có anh Hoành cũng như cả cộng đồng CadViet)

Tuy nhiên, ssg e rằng sẽ không thể tiếp tục được nữa nếu như chưa hiểu rõ toàn bộ những việc cần làm tiếp theo trong việc xây dựng bản đồ, bản vẽ, file lưu trữ, hồ sơ... (trước mắt là cho mảng địa chính). Các bạn không giúp ssg thông suốt một cách triệt để thì cũng đành bó tay thôi!

 

P/S: Cám ơn vndes! Mình viết xong mấy ý trên mới đọc bài của bạn. Có lẽ bạn là người hiểu rõ nhất cái khó hiện nay của ssg.

Gay quá, vẫn chưa tìm được tiếng nói chung. Thôi thì thế này, mình gửi một "bộ" các file, mong rằng hệ thống được q

Chia sẻ bài đăng này


Liên kết tới bài đăng
Chia sẻ trên các trang web khác
A- Cái này thì ssg căn cứ vào điểm point trọng tâm - Centroid, hình thù thửa phức tạp kệ nó ko sao. elle sẽ giúp ssg giải thuật này kể cả giải thuật xác định Centroid vì elle đã từng làm rồi, khó nhất là elle viết ko phải bằng lisp mà trên delphi để tạo file chạy *.exe nên tất cả các hàm tính đó elle phải "tính bộ" hết chứ ko tận dụng được các hàm của lisp hay Cad.

 

B- Lâu công nhất là cái này vì hầu như user phải nhập tay. Cad có làm đc ko thì mình ko rõ vì số liệu này thường hiểu theo kiểu Database để Link (kết nối) với Cad. Drawing thuộc khái niệm "không gian" còn database thuộc khái niệm phi không gian mà. Nếu đưa hết Sothua, DienTich, TenChu, DiaChi, LoaiDat v.v...hiển thị hết trên bản vẽ thì rối lắm, người ta chỉ để SoThua, DienTich, LoaiDat hiện lên trên bản vẽ thôi. Mình cũng chưa nghĩ nên làm thế nào cho tiện đây.

A- Chỗ này mình hỏi lại cho chắc thôi. Lisp có thể xác định toạ độ centroid của bất cứ hình gì có trên bản vẽ.

 

B- Mình ủng hộ ý kiến "nhà máy sản xuất hồ sơ" của bạn. Điều này hoàn toàn khả thi trong khả năng của Lisp. Cái vướng nhất chính là các thông tin: Loại đất, Chủ sử dụng và Địa chỉ. Tất nhiên, số liệu ban đầu thì phải nhập tay, nhưng nhập ở đâu, nhập như thế nào cần nghiên cứu kỹ hơn. Mình đề xuất cách làm như sau:

 

1) Việc tạo Closed Pline user tự làm. Không có AutoCad Map thì làm thủ công bằng lệnh boundary hay bằng cách gì đó tuỳ ý.

 

2) Khi đã có đầy đủ các Closed Plines, chương trình sẽ đánh số thửa và ghi diện tích tự động tại điểm centroid của thửa. Lại phải hỏi cho rõ: con số thứ tự thửa (ST), line phân cách hay là con số diện tích trùng với centroid của thửa? Justify các thành phần như thế nào? Theo mình, lấy ST (justify center) làm chuẩn cho nó trùng với centroid thửa vì nó là key để nhận biết các thành phần khác, bất kể trong bản vẽ *.dwg hay trong file database.

 

3) Khi làm động tác trên, chương trình có khả năng ghi nhận những dữ liệu sau về toàn bộ các thửa đất và có thể ghi ra file database (dùng dạng *.csv là hợp lý nhất):

- Số thứ tự thửa (ST)

- Diện tích

- Toạ độ tất cả các đỉnh thửa

- Toạ độ centroid thửa

Tóm lại là đủ dữ liệu cần thiết để tái hiện lại hình dáng kích thước của 1 thửa bất kỳ. Với file *.csv, user có thể dễ dàng dùng Excel để open và bổ sung thêm các field: LoaiDat, ChuSuDung, DiaChi...

Với file database như vậy, user chỉ cần cung cấp ST là có ngay hồ sơ kỹ thuật thửa đất, chẳng cần đến file *.dwg tổng thể nữa.

 

Phương hướng chung là vậy, nhưng để triển khai cần phải chi tiết hơn, chi tiết đến "từng sợi tóc" như mình đã phân tích hôm nọ.

Các bạn xem và góp ý thêm. Cứ bàn bạc thoải mái, nhưng cuối cùng phải đi đến thống nhất và kết luận. Không có kết luận, LCV xem như giậm chân tại chỗ!

 

P/S: Ssg bận việc, có lẽ vắng diễn đàn mấy ngày. Hôm nào go back sẽ bàn tiếp.

  • Vote tăng 1

Chia sẻ bài đăng này


Liên kết tới bài đăng
Chia sẻ trên các trang web khác
Cám ơn các ý kiến, và đặc biệt là file vd của bạn. Ssg đã nói từ lâu rồi nhưng hình như các bạn không chú ý lắm. Kiến thức mà ssg đang thiếu chính là cái nhìn tổng quan ấy. File ví dụ người thật việc thật của bạn có tác dụng cực kỳ quan trọng trong việc định hướng để xây dựng chương trình. Nếu định hướng sai lầm ban đầu sẽ dẫn đến việc tốn nhiều công sức nhưng kết quả không đạt được như mong muốn. Với khu đất có 10 thửa và khu đất có 1000 thửa, tư duy lập trình khác nhau rất nhiều!

Với số lượng thửa như ví dụ của bạn, rõ ràng việc pick từng thửa để đánh số là không ổn. Ssg nhất trí với phương án đánh số tự động mà bạn nêu. Nhưng còn mấy điểm chưa rõ:

1) Đánh số theo chiều từ trái qua phải, từ trên xuống dưới thì hiểu rồi. Nhưng căn cứ vào điểm (point) nào, có phải là theo trọng tâm của thửa đất không? Hay là theo điểm cực Tây và cực Bắc của nó? (hình dạng nhiều thửa đất rất phức tạp, không vuông vắn như ô bàn cờ!)

2) Thông tin về Loại đất, Chủ sử dụng và Địa chỉ như tnmtpc nêu thì nhập như thế nào?

3) Hôm nọ hình như các bạn đã thống nhất ý kiến không dùng attribute block mà chỉ nên dùng text thôi?

4) Còn một số câu hỏi "như thế nào" tương tự như trên nữa chưa xuất hiện! Chúng chỉ lộ diện khi ssg coding xong và các bạn dùng thử mới thấy không ổn!

 

Kết luận:

Qua 1 đoạn thử nghiệm đã làm được, các bạn có thể thấy rõ là Lisp có khả năng rất lớn, có thể giúp chúng ta tăng năng suất làm việc lên nhiều lần. Bản thân ssg, tuy khả năng và hiểu biết có hạn, vẫn có thể cụ thể hoá nhiều ý tưởng thành chương trình (chỗ nào bí đã có anh Hoành cũng như cả cộng đồng CadViet)

Tuy nhiên, ssg e rằng sẽ không thể tiếp tục được nữa nếu như chưa hiểu rõ toàn bộ những việc cần làm tiếp theo trong việc xây dựng bản đồ, bản vẽ, file lưu trữ, hồ sơ... (trước mắt là cho mảng địa chính). Các bạn không giúp ssg thông suốt một cách triệt để thì cũng đành bó tay thôi!

 

P/S: Cám ơn vndes! Mình viết xong mấy ý trên mới đọc bài của bạn. Có lẽ bạn là người hiểu rõ nhất cái khó hiện nay của ssg.

Gay quá vẫn còn trục trặc đây, thôi thì thế này, mình gửi một "bộ" gồm các file, hy vọng rằng nó bao quát được qui trình của một sản phẩm địa chính.

File bản vẽ được hình thành từ số liệu đo thông qua import data và xử lý mã (cái này LCV đã làm được), trong mỗi thửa có tâm thửa, các text được định vị theo nó, số thửa, diện tích được ghi tự động (trong đó có một số thửa không theo qui luật là do phát sinh sau khi đánh số tự động xong, gọi là số thêm)

Sau khi hoàn thành xong bản đồ, bước tiếp theo là tạo ra hệ thống sổ sách theo qui định, giai đoạn này cần qua khâu trung gian là nhờ access để tạo và quản lý dữ liệu thuộc tính (khâu này rất phức tạp)( các file trong thư mục data), kết quả tạo ra các mẫu sổ (sổ địa chính, sổ mục kê, sổ cấp giấy), các mẫu này được chuyển sang định dạng .pdf để in ấn

sản phẩm khác là hồ sơ kỷ thuật thửa đất và trích lục

Có thể tóm tắt qui trình như sau:

1/Tạo dữ liệu không gian: từ số liệu đo đã chuẩn hóa, chuyển sang Cad, tạo thửa, tạo tâm thửa, đánh số thửa và ghi diện tích tự động, nhập loại đất và tên chủ sử dụng (cần nhập thêm thông tin địa chỉ), làm các việc linh tinh khác để hoàn thành bản đồ

2/ tạo dữ liệu thuộc tính (phi không gian)

Đối với thửa đất có các dữ liệu: số thửa, diện tích, loại đất (một số thông tin khác như hạng đất được đưa vào sau)

Đối với chủ sử dụng có các thông tin: tên chủ sử dụng, năm sinh, CMND, ngày và nơi cấp- Tên vợ (hoặc chồng),năm sinh, CMND, ngày và nơi cấp- địa chỉ thường trú...

Vấn đề đặt ra là dữ liệu thuộc tính được làm ở đâu? LCV có thực hiện được không và có lưu file dữ liệu thuộc tính với một dạng file nào đó. Giải pháp khả dĩ là thực hiện trên excel hoặc sử dụng chức năng table trong cad ?(cái này mình không rành)

3/ Tạo hồ sơ kỷ thuật và trích lục: có hai hình thức: tạo tự động hàng loạt và tạo từng thửa theo nhu cầu của user

Còn một số công việc khác nữa của địa chính, nhưng sẽ đề cập sau

http://www.cadviet.com/upfiles/file_mau_lcv.rar

(tên layer trong file này không giống file trước đây mình gửi, vì do chương trình xử lý khác nhau)

Chia sẻ bài đăng này


Liên kết tới bài đăng
Chia sẻ trên các trang web khác
Trong đo đạc địa chính elle đã từng gặp 1 khu đo khoảng 500ha cần giải phóng mặt bằng để xây dựng khu đô thị mới và có khoảng 3000 thửa thì chắc làm theo phương án này là không khả quan vì rất chậm, hay nhầm lẫn. Phương án là khi CT chạy hỏi "select close polyline" vẫn hay hơn, nghĩa là chọn một tập hợp các thửa để cho CT chạy. Nó tiện vì có thể đánh được số thửa tự động và làm hàng loạt như một "nhà máy sản xuất hồ sơ". Việc tạo một "Close Polyline" hãy để cho user đảm trách, dễ thôi vì những ai làm bản đồ thì hay cài AutoCAD Map chứ ko hay cài AutoCAD và tạo "Close Polyline" chỉ là một việc đơn giản trong tích tắc. AutoCAD Map có hàng loạt cộng cụ có sẳn để làm việc này.

Tnmtpc có nhất trí với quan điểm này không? Có được tập hợp các đối tượng Closed Polyline (hoặc Region), mỗi đối tượng biểu diễn 1 thửa đất -> các bạn muốn yêu cầu kiểu gì cũng được!

  • Vote tăng 1

Chia sẻ bài đăng này


Liên kết tới bài đăng
Chia sẻ trên các trang web khác
Tnmtpc có nhất trí với quan điểm này không? Có được tập hợp các đối tượng Closed Polyline (hoặc Region), mỗi đối tượng biểu diễn 1 thửa đất -> các bạn muốn yêu cầu kiểu gì cũng được!

Ok! Việc tạo Closed Polyline (hoặc Region), đơn giản thôi mà. Nhất trí như vậy nhé

  • Vote tăng 1

Chia sẻ bài đăng này


Liên kết tới bài đăng
Chia sẻ trên các trang web khác
Nhất trí với Ssg và ủng hộ hết mình. Tnmtpc sẽ cố trong thời gian sớm nhất gửi bảng tổng hợp các yêu cầu và hai file *.dwg và *.xls để có cơ sở nghiên cứu chương trình

Giá như Ssg Ssg am tường về trắc địa hoặc tnmtpc có được kiến thức về lisp như Bác Ssg nhỉ. Mà sao các Bác trắc địa không ai lên tiếng vậy cà?

Chào tất cả các bạn. Tôi mới tham gia diễn đàn. Tôi cũng là dân Trắc địa.

1-Tôi thấy món bản đồ thường bị mất thời gian ở công đoạn tu chỉnh để in ấn. Ví dụ với bản đồ địa chính: để in ra giấy thì các thông tin về thửa như số thửa, diện tích, loại đất, gạch phân cách bị chồng đè vào các yếu tố khác. Vậy phải xoay, hoặc di chuyển ra vị trí khác, vậy các bạn nên làm 1 modul nhỏ để xoay, di chuyển cụm thông tin này theo 1 hướng nào đó tuỳ chọn

2- Sau khi các thông tin của bản đồ được xuất ra file excel thì khi thay đổi thông tin về tên chủ, địc chỉ, loại đất phải sửa trên file excel. Vậy nên làm modul để trút ngược lại thông tin đã sửa trên file excel vào bản đồ (theo dúng vị trí cảu thửa).

(thông tin ra file excel gồm 6 cột là: tên từ bản đồ, thửa số, diện tích, loại đất, tên chủ, địa chỉ)

3- Làm modul để lấy toạ độ xyz của các điểm, các line trên bản vẽ, xuất ra file excel. vì thường số lượng điểm trên bản đồ rất nhiều nên không thể đọc toạ độ từng điểm được.

4- Về in ấn. Với ngành địa chính pthường phải in số lượng bản vẽ nhiều (như hồ sơ kỹ thuật thửa đất).mà cứ phải mở từng file ra và pick để gửi ra máy in thì rất lâu (các bản vẽ này giống nhau về vị trí , kích cỡ của hình vẽ). Vậy làm sao để in tự động hết các file bản vẽ trong thư mục đã chọn ?

Chia sẻ bài đăng này


Liên kết tới bài đăng
Chia sẻ trên các trang web khác

Tạo một tài khoản hoặc đăng nhập để nhận xét

Bạn cần phải là một thành viên để lại một bình luận

Tạo tài khoản

Đăng ký một tài khoản mới trong cộng đồng của chúng tôi. Điều đó dễ mà.

Đăng ký tài khoản mới

Đăng nhập

Bạn có sẵn sàng để tạo một tài khoản ? Đăng nhập tại đây.

Đăng nhập ngay

×