Đến nội dung


Hình ảnh
- - - - -

LandCadViet Utility


  • Please log in to reply
149 replies to this topic

#61 tnmtpc

tnmtpc

    biết dimcontinue

  • Members
  • PipPipPipPipPip
  • 370 Bài viết
Điểm đánh giá: 206 (khá)

Đã gửi 20 March 2008 - 11:19 AM

Các bạn xem và góp ý cho cái này:

Hình đã gửi

1) Giao diện nhập liệu như vậy được không? Cần chỉnh sửa gì thêm cho "bắt mắt" hơn?
Mình có ý là muốn chèn thêm 1 logo của LCV vào cho nó... hoành tráng! Nếu các bạn thấy thích thì sáng tác và post lên.
Yêu cầu: đơn giản, ấn tượng, nhìn vào là biết ngay LandCadViet. Hình thức: là các đối tượng *.dwg.

2) Thông qua giao diện có thể thấy cụ thể hơn chức năng và cung cách hoạt động của chương trình:
- Người dùng tuỳ chọn "Trường hợp áp dụng". Nếu chọn "Địa chính", các popup_list "Z" và "Cao do" sẽ disable (mờ đi)
- File dữ liệu: có thể nhập trực tiếp vào box hoặc dùng "Browse"
- Thứ tự các fields: theo đúng ý tnmtpc. Mặc định như hiển thị trên hình, người dùng muốn thay đổi tuỳ ý
- File thư viện các địa vật: giống như trên
- Chọn Layer cho các yếu tố: mặc định như hiển thị trên hình, người dùng tuỳ ý thay đổi. Nói chung, người dùng nên tạo trước các Layer có tên như trên và thiết lập màu sắc, đường nét... theo ý thích. Nếu không có, chương trình sẽ tự tạo các Layer với thiết lập màu White, ltype Continuous.
- Chiều cao text cao độ: con số mặc định là TextSize hiện hành, người dùng tuỳ ý thay đổi.

Tùy chọn file thư viện địa vật không thể đưa vào hộp thoại này được, vì lý do sau:
trong file cad sẽ có rất nhiều ký hiệu địa vật khác nhau cần thể hiện trên bản vẽ, nhưng trong hộp thoại chỉ được phép chọn một kiểu ("vd1.dwg"), nên sửa lại như sau: sau khi import dữ liệu, trên bản vẽ, tại các điểm đăc biệt có các mã địa vật (VD: CAYDOCLAP, LK, TRUDIEN...), dùng lệnh cho hiển thị các ký hiệu địa vật theo mã tương ứng, điều này có nghĩa là sẽ phải sử dụng một hộp thoại riêng, trong đó có một editbox để nhập mã, một editbox thể hiện đường dẫn đến files ký hiệu cần chọn, thực hiện xong mã này tiếp tục thực hiện cho các mã khác (ví dụ nhập LK, chọn file ký hiệu lỗ khoan, enter, tại các điểm có mã LK trên bản vẽ sẽ được chèn symbol lỗ khoan, tiếp tục các mã khác...)
  • -1

#62 ssg

ssg

    biết lệnh adcenter

  • Vip
  • PipPipPipPipPipPipPip
  • 1228 Bài viết
Điểm đánh giá: 1087 (rất tốt)

Đã gửi 20 March 2008 - 02:51 PM

Cám ơn các bạn đã tham gia ý kiến rất nhiệt tình. Đúng là có hình ảnh dễ nói chuyện hơn.
Mình đã cân nhắc mọi ý kiến của tất cả các bạn và đề nghị như sau:

1) Về thứ tự các field:
Mình ủng hộ ý kiến của vndes, bỏ quách mấy cái popup_list tuỳ chọn đi. Chương trình sẽ căn cứ vào Header trong file dữ liệu để lấy FieldName lẫn thứ tự Fields. Người dùng không phải lăn tăn chuyện này nữa, trong file dữ liệu muốn đặt theo thứ tự nào cũng được. Để làm theo hướng này, có mấy ý sau:
- FieldNames phải thống nhất theo quy ước. Ví dụ: Tendiem - X - Y - Z - Code - Ghichu. Anh nào lỡ lập FieldName không đúng thì tự sửa lại theo chuẩn. Không sửa thì chương trình không chạy!
- Theo mình, cũng không cần preview các Fields. Nếu tuân thủ quy ước trên, chương trình luôn luôn nhận biết chính xác 100% FieldNames và thứ tự. Yên tâm đi!
- Theo ý bạn elleHCSC, cứ có đủ 3 thằng: Tendiem, X, Y là "bắn". Những cái còn lại, chương trình sẽ tự nhận biết: có thì chơi, không có thì thôi.
- Đã như vậy, có khi cũng nên bỏ luôn tuỳ chọn Địa hình/Địa chính? (trong file dữ liệu, nếu có Z là địa hình, không có Z là địa chính). Chỗ này mình không rành lắm, tuỳ ý các bạn.

2) Về thư viện địa vật:
Ban đầu mình nghĩ là các địa vật dạng blocks ở trong 1 file nào đó. Nhưng theo cách các bạn diễn giải thì mỗi địa vật nằm trong 1 file, chứa trong 1 thư mục nào đó. Đúng không?
Nếu làm như tnmtpc thì phiền toái quá. Ví dụ, có vài chục (hoặc vài trăm) cái địa vật cũng bắt người dùng thao tác liên tục à? Như vậy có khác gì dùng lệnh insert của Acad?
Chương trình có thể làm tự động loạt thao tác đó, chỉ cần 1 trong 2 điều kiện:
a- Biết trước đường dẫn của thư mục thư viện
b- Không biết đường dẫn, nhưng thư mục thư viện phải được thiết lập Support File Search Path
Mình thiên về hướng a-, tức là LandCadViet sẽ lập sắn thư mục có tên ...\LCV\Libraries, người dùng sưu tầm được cái gì cứ quẳng vào trong đó. Chương trình căn cứ vào nội dung trong field "Ghichu", nếu tìm thấy trong Libraries thì tự động insert vào, không có thì thôi.
Riêng tỷ lệ insert, người dùng chỉ có thể chọn 1 scale chung trên dialog. Cái nào không hợp thì vui lòng tự biên tập lại trong bản vẽ. Lúc nào rảnh thì sửa lại các file thư viện theo 1 quy cách thống nhất.

3) Ý vndes nói thêm 1 nút Default trong phần chọn Layer nghĩa là thế nào? Theo mình thuyết minh trên, khi bắt đầu load dialog, chương trình sẽ tự thiết lập layers như đang hiển thị trên hình, đó chính là các giá trị default. Người dùng không muốn thay đổi thì không cần động tay vào.

4) Về chiều cao text, hôm trước mình có nghe bạn nào đó trong ngành giải thích rằng lấy text Caodo làm chuẩn, các text khác lấy bằng 1/2 kia mà? Nếu thấy cần thì thêm cái Tendiem vào, không vấn đề gì. Nhưng nếu không cần thì thôi, quan điểm chung là dialog nhập liệu càng đơn giản càng tốt.

Mong các bạn tiếp tục đóng góp ý kiến và cho kết luận cuối cùng. Có thống nhất phương án mới coding được.
  • 0

#63 tnmtpc

tnmtpc

    biết dimcontinue

  • Members
  • PipPipPipPipPip
  • 370 Bài viết
Điểm đánh giá: 206 (khá)

Đã gửi 20 March 2008 - 04:35 PM

Cám ơn các bạn đã tham gia ý kiến rất nhiệt tình. Đúng là có hình ảnh dễ nói chuyện hơn.
Mình đã cân nhắc mọi ý kiến của tất cả các bạn và đề nghị như sau:

1) Về thứ tự các field:
Mình ủng hộ ý kiến của vndes, bỏ quách mấy cái popup_list tuỳ chọn đi. Chương trình sẽ căn cứ vào Header trong file dữ liệu để lấy FieldName lẫn thứ tự Fields. Người dùng không phải lăn tăn chuyện này nữa, trong file dữ liệu muốn đặt theo thứ tự nào cũng được. Để làm theo hướng này, có mấy ý sau:
- FieldNames phải thống nhất theo quy ước. Ví dụ: Tendiem - X - Y - Z - Code - Ghichu. Anh nào lỡ lập FieldName không đúng thì tự sửa lại theo chuẩn. Không sửa thì chương trình không chạy!
- Theo mình, cũng không cần preview các Fields. Nếu tuân thủ quy ước trên, chương trình luôn luôn nhận biết chính xác 100% FieldNames và thứ tự. Yên tâm đi!
- Theo ý bạn elleHCSC, cứ có đủ 3 thằng: Tendiem, X, Y là "bắn". Những cái còn lại, chương trình sẽ tự nhận biết: có thì chơi, không có thì thôi.
- Đã như vậy, có khi cũng nên bỏ luôn tuỳ chọn Địa hình/Địa chính? (trong file dữ liệu, nếu có Z là địa hình, không có Z là địa chính). Chỗ này mình không rành lắm, tuỳ ý các bạn.

2) Về thư viện địa vật:
Ban đầu mình nghĩ là các địa vật dạng blocks ở trong 1 file nào đó. Nhưng theo cách các bạn diễn giải thì mỗi địa vật nằm trong 1 file, chứa trong 1 thư mục nào đó. Đúng không?
Nếu làm như tnmtpc thì phiền toái quá. Ví dụ, có vài chục (hoặc vài trăm) cái địa vật cũng bắt người dùng thao tác liên tục à? Như vậy có khác gì dùng lệnh insert của Acad?
Chương trình có thể làm tự động loạt thao tác đó, chỉ cần 1 trong 2 điều kiện:
a- Biết trước đường dẫn của thư mục thư viện
b- Không biết đường dẫn, nhưng thư mục thư viện phải được thiết lập Support File Search Path
Mình thiên về hướng a-, tức là LandCadViet sẽ lập sắn thư mục có tên ...\LCV\Libraries, người dùng sưu tầm được cái gì cứ quẳng vào trong đó. Chương trình căn cứ vào nội dung trong field "Ghichu", nếu tìm thấy trong Libraries thì tự động insert vào, không có thì thôi.
Riêng tỷ lệ insert, người dùng chỉ có thể chọn 1 scale chung trên dialog. Cái nào không hợp thì vui lòng tự biên tập lại trong bản vẽ. Lúc nào rảnh thì sửa lại các file thư viện theo 1 quy cách thống nhất.

3) Ý vndes nói thêm 1 nút Default trong phần chọn Layer nghĩa là thế nào? Theo mình thuyết minh trên, khi bắt đầu load dialog, chương trình sẽ tự thiết lập layers như đang hiển thị trên hình, đó chính là các giá trị default. Người dùng không muốn thay đổi thì không cần động tay vào.

4) Về chiều cao text, hôm trước mình có nghe bạn nào đó trong ngành giải thích rằng lấy text Caodo làm chuẩn, các text khác lấy bằng 1/2 kia mà? Nếu thấy cần thì thêm cái Tendiem vào, không vấn đề gì. Nhưng nếu không cần thì thôi, quan điểm chung là dialog nhập liệu càng đơn giản càng tốt.

Mong các bạn tiếp tục đóng góp ý kiến và cho kết luận cuối cùng. Có thống nhất phương án mới coding được.

Mấy vấn đề tham gia:
1/Thứ tự các trường: để đơn giản cho lập trình, chương trình nhận biết chính xác, các surveyer chịu khó biên tập file dữ liệu đúng theo thứ tự :Tendiem - X - Y - Z - Code - Ghichu(việc này đơn giản thôi mà), tuy nhiên việc bỏ luôn tùy chọn địa chính/địa hình là không nên, bỡi vì trong một vài trường hợp, khi xử lý số liệu đo, file dữ liệu kết quả có đầy đủ các cột Tendiem - X - Y - Z - Code - Ghichu. nếu sử dụng file này để thành lập bản vẽ địa chính thì phải xóa cột Z đi, rồi sau này vì một nhu cầu nào đó, cần tham khảo độ cao của vùng, lấy gì để thể hiện độ cao? (hay là lưu 2 file dữ liệu một lúc?)Theo TNMTPC thì nên thay 2 cái nút bản vẽ địa hình-bản vẽ địa chính thành một nút Bật/tắt chức năng hiển thị độ cao thì có vẻ pro hơn
2/về thư viện địa vật: theo ý SSg thì chương trình chỉ gán một lần, có nghĩa là chương trình phải có một "kho" chứa các mã địa vật để nhận biết tất cả các mã có trong file dữ liệu, điều này là không khả thi, chưa kể mỗi surveyer có thể "thiết kế" mã khác nhau(ví dụ "cây độc lập" có thể có mã CAYDOCLAP hoặc CDL). Như TNMTPC đã trình bày, sau khi nhập dữ liệu xong, chèn ký hiệu bằng cách "nơi nào có mã LK thì chèn symbol lỗ khoan vào...", nếu có 100 lỗ khoan cũng chỉ một lần nhấn enter, SSg yên tâm đi, trong một file không đến nỗi có tới vài trăm loại địa vật đâu, mà nếu có cũng phải nhấn enter vài trăm lần chứ sao, không nên ràng buột đường dẫn thư viện cố định, SSg có thể chưa hình dung, cái kho thư viện này nó đa dạng lắm, về scale: tùy theo nhu cầu, bản vẽ khi in ra có tỷ lệ khác nhau, nếu symbol LK sử dụng cho bản vẽ tỷ lệ 1/1000 là phù hợp, nếu chèn vào bản vẽ tỷ lệ 1/500 thì scale =2 mới xem được, nếu cứ chèn đại sau đó edit thì gay quá, cũng không thể tạo thư viện riêng cho từng lọai tỷ lệ sẽ hao tốn tài nguyên
  • 0

#64 ssg

ssg

    biết lệnh adcenter

  • Vip
  • PipPipPipPipPipPipPip
  • 1228 Bài viết
Điểm đánh giá: 1087 (rất tốt)

Đã gửi 21 March 2008 - 08:43 AM

Mấy vấn đề tham gia:
1/Thứ tự các trường: để đơn giản cho lập trình, chương trình nhận biết chính xác, các surveyer chịu khó biên tập file dữ liệu đúng theo thứ tự :Tendiem - X - Y - Z - Code - Ghichu(việc này đơn giản thôi mà), tuy nhiên việc bỏ luôn tùy chọn địa chính/địa hình là không nên, bỡi vì trong một vài trường hợp, khi xử lý số liệu đo, file dữ liệu kết quả có đầy đủ các cột Tendiem - X - Y - Z - Code - Ghichu. nếu sử dụng file này để thành lập bản vẽ địa chính thì phải xóa cột Z đi, rồi sau này vì một nhu cầu nào đó, cần tham khảo độ cao của vùng, lấy gì để thể hiện độ cao? (hay là lưu 2 file dữ liệu một lúc?)Theo TNMTPC thì nên thay 2 cái nút bản vẽ địa hình-bản vẽ địa chính thành một nút Bật/tắt chức năng hiển thị độ cao thì có vẻ pro hơn
2/về thư viện địa vật: theo ý SSg thì chương trình chỉ gán một lần, có nghĩa là chương trình phải có một "kho" chứa các mã địa vật để nhận biết tất cả các mã có trong file dữ liệu, điều này là không khả thi, chưa kể mỗi surveyer có thể "thiết kế" mã khác nhau(ví dụ "cây độc lập" có thể có mã CAYDOCLAP hoặc CDL). Như TNMTPC đã trình bày, sau khi nhập dữ liệu xong, chèn ký hiệu bằng cách "nơi nào có mã LK thì chèn symbol lỗ khoan vào...", nếu có 100 lỗ khoan cũng chỉ một lần nhấn enter, SSg yên tâm đi, trong một file không đến nỗi có tới vài trăm loại địa vật đâu, mà nếu có cũng phải nhấn enter vài trăm lần chứ sao, không nên ràng buột đường dẫn thư viện cố định, SSg có thể chưa hình dung, cái kho thư viện này nó đa dạng lắm, về scale: tùy theo nhu cầu, bản vẽ khi in ra có tỷ lệ khác nhau, nếu symbol LK sử dụng cho bản vẽ tỷ lệ 1/1000 là phù hợp, nếu chèn vào bản vẽ tỷ lệ 1/500 thì scale =2 mới xem được, nếu cứ chèn đại sau đó edit thì gay quá, cũng không thể tạo thư viện riêng cho từng lọai tỷ lệ sẽ hao tốn tài nguyên


1) Không yêu cầu đúng thứ tự mà chỉ cần đúng tên Fields theo quy ước (cái này càng đơn giản hơn, người dùng chỉ cần sửa 1 dòng header của file dữ liệu). Ví dụ, đã quy ước "Tendiem" thì không được phép viết "Ten diem". Đúng thứ tự nhưng tên fields đặt không theo chuẩn cũng vô ích thôi vì như các bạn đã nói, có thể trong file dữ liệu không có đủ 6 thành phần. Ví dụ:
File1 có: Tendiem - X - Y - Z
File2 có: Tendiem - X - Y - Ghichu
File3 có: Tendiem - X - Y - Code
Nếu chỉ căn cứ vào thứ tự, chương trình không thể biết được field thứ 4 là cái gì!

2) Đã phức tạp vậy thì phải chấp nhận. Tuy nhiên, mình vẫn còn thắc mắc: trong file ví dụ của bạn, ở cột Ghichu, thống kê được 6 cái tên: Tdien, bien song, muong, bo ao, ao. Theo cách hiếu của chương trình, cả 6 cái trên có cùng một kiểu với nhau. Trong khi đó, trên bản vẽ chỉ có mỗi một cái Tdien được chèn vào. Làm thế nào để biết là cái nào là địa vật cần insert, cái nào là "Ghi chú khác"?
Một biện pháp khả dĩ: hiện một list_box để người dùng tuỳ ý chọn cái nào cần insert được không?

Việc cần làm lúc này là bạn chịu khó biên tập lại các file ví dụ theo đúng yêu cầu mình đã nêu hôm nọ. Lưu ý thêm về tính điển hình của ví dụ. Tốt nhất là bê nguyên xi các bảng dữ liệu và bản vẽ có quy mô trung bình mà các bạn thường làm trong công việc hàng ngày. Mục đích: giúp người lập trình có cái nhìn toàn diện và sâu sắc hơn. Nếu ngại kích thước file lớn quá thì trích đoạn cũng được, nhưng phải chú thích thêm là quy mô đoạn trích cỡ bằng bao nhiêu % trong thực tế.
Xin nhấn mạnh thêm, để xây dựng một ứng dụng như LCV, việc định hướng để xây dựng nên cái sườn cho chương trình (như anh em mình góp ý mấy hôm nay) là cực kỳ quan trọng. Công việc coding, tuy cũng tốn khá nhiều công sức, nhưng chỉ đóng vai trò thứ yếu, chỉ đơn thuần là cụ thể hoá các ý tưởng của "cái sườn" nói trên thôi. Chính vì thế, các bạn đừng ngại việc phải bàn bạc nhiều lần. Làm càng kỹ bước này thì việc coding càng nhẹ nhàng và hiệu quả.
Nói như vậy cũng không có nghĩa là bàn tới bàn lui hoài mà không thấy kết quả ở đâu. Thu thập ý kiến nhiều người là cần thiết nhưng phải chốt lại vấn đề. Về chuyên môn, ssg cũng đã từng đề cập rồi, bạn là người chủ trì, bạn phải có kết luận cuối cùng. Ssg sẽ căn cứ vào cái kết luận ấy của bạn để cụ thể hoá nó thành chương trình.
  • 0

#65 tnmtpc

tnmtpc

    biết dimcontinue

  • Members
  • PipPipPipPipPip
  • 370 Bài viết
Điểm đánh giá: 206 (khá)

Đã gửi 21 March 2008 - 09:14 PM

1) Không yêu cầu đúng thứ tự mà chỉ cần đúng tên Fields theo quy ước (cái này càng đơn giản hơn, người dùng chỉ cần sửa 1 dòng header của file dữ liệu). Ví dụ, đã quy ước "Tendiem" thì không được phép viết "Ten diem". Đúng thứ tự nhưng tên fields đặt không theo chuẩn cũng vô ích thôi vì như các bạn đã nói, có thể trong file dữ liệu không có đủ 6 thành phần. Ví dụ:
File1 có: Tendiem - X - Y - Z
File2 có: Tendiem - X - Y - Ghichu
File3 có: Tendiem - X - Y - Code
Nếu chỉ căn cứ vào thứ tự, chương trình không thể biết được field thứ 4 là cái gì!

2) Đã phức tạp vậy thì phải chấp nhận. Tuy nhiên, mình vẫn còn thắc mắc: trong file ví dụ của bạn, ở cột Ghichu, thống kê được 6 cái tên: Tdien, bien song, muong, bo ao, ao. Theo cách hiếu của chương trình, cả 6 cái trên có cùng một kiểu với nhau. Trong khi đó, trên bản vẽ chỉ có mỗi một cái Tdien được chèn vào. Làm thế nào để biết là cái nào là địa vật cần insert, cái nào là "Ghi chú khác"?
Một biện pháp khả dĩ: hiện một list_box để người dùng tuỳ ý chọn cái nào cần insert được không?

Việc cần làm lúc này là bạn chịu khó biên tập lại các file ví dụ theo đúng yêu cầu mình đã nêu hôm nọ. Lưu ý thêm về tính điển hình của ví dụ. Tốt nhất là bê nguyên xi các bảng dữ liệu và bản vẽ có quy mô trung bình mà các bạn thường làm trong công việc hàng ngày. Mục đích: giúp người lập trình có cái nhìn toàn diện và sâu sắc hơn. Nếu ngại kích thước file lớn quá thì trích đoạn cũng được, nhưng phải chú thích thêm là quy mô đoạn trích cỡ bằng bao nhiêu % trong thực tế.
Xin nhấn mạnh thêm, để xây dựng một ứng dụng như LCV, việc định hướng để xây dựng nên cái sườn cho chương trình (như anh em mình góp ý mấy hôm nay) là cực kỳ quan trọng. Công việc coding, tuy cũng tốn khá nhiều công sức, nhưng chỉ đóng vai trò thứ yếu, chỉ đơn thuần là cụ thể hoá các ý tưởng của "cái sườn" nói trên thôi. Chính vì thế, các bạn đừng ngại việc phải bàn bạc nhiều lần. Làm càng kỹ bước này thì việc coding càng nhẹ nhàng và hiệu quả.
Nói như vậy cũng không có nghĩa là bàn tới bàn lui hoài mà không thấy kết quả ở đâu. Thu thập ý kiến nhiều người là cần thiết nhưng phải chốt lại vấn đề. Về chuyên môn, ssg cũng đã từng đề cập rồi, bạn là người chủ trì, bạn phải có kết luận cuối cùng. Ssg sẽ căn cứ vào cái kết luận ấy của bạn để cụ thể hoá nó thành chương trình.

TNMTPC gửi SSg một số file theo gợi ý để SSg có khái niệm cụ thể hơn, mong các chuyên gia trắc địa tham khảo để góp ý cho LandCadViet Utility
http://www.cadviet.c...iet_Utility.rar
  • 0

#66 ssg

ssg

    biết lệnh adcenter

  • Vip
  • PipPipPipPipPipPipPip
  • 1228 Bài viết
Điểm đánh giá: 1087 (rất tốt)

Đã gửi 24 March 2008 - 08:29 AM

TNMTPC gửi SSg một số file theo gợi ý để SSg có khái niệm cụ thể hơn, mong các chuyên gia trắc địa tham khảo để góp ý cho LandCadViet Utility
http://www.cadviet.com/upfiles/LandCadViet_Utility.rar

Bạn vẫn chưa gởi cho mình các file *.tab, *.txt, *.xyh
Những cái này rất cần thiết để có giải pháp toàn diện khi xây dựng thuật giải Convert File to List.
  • 0

#67 vndesperados

vndesperados

    biết lệnh xref

  • Members
  • PipPipPipPipPipPipPip
  • 547 Bài viết
Điểm đánh giá: 253 (khá)

Đã gửi 24 March 2008 - 10:12 AM

TNMTPC gửi SSg một số file theo gợi ý để SSg có khái niệm cụ thể hơn, mong các chuyên gia trắc địa tham khảo để góp ý cho LandCadViet Utility
http://www.cadviet.com/upfiles/LandCadViet_Utility.rar


Bác có thể mô phỏng trên FreeMind không???
Như thế đọc đỡ mệt hơn mà ý nghĩa trình bày rõ ràng hơn.
  • 0

#68 tnmtpc

tnmtpc

    biết dimcontinue

  • Members
  • PipPipPipPipPip
  • 370 Bài viết
Điểm đánh giá: 206 (khá)

Đã gửi 24 March 2008 - 10:32 AM

Bạn vẫn chưa gởi cho mình các file *.tab, *.txt, *.xyh
Những cái này rất cần thiết để có giải pháp toàn diện khi xây dựng thuật giải Convert File to List.

*.tab, *.txt, *.xyh... tất cả đều là text file, mỗi loại có một bố cục khác nhau trong file, thông thường khác nhau ở các dòng đầu tiên, những dòng này thể hiện thông tin về trạm máy, điểm định hướng...mỗi loại file do một thiết bị đo hoặc chương trình xử lý riêng tạo ra chỉ giao tiếp với một chương trình riêng biệt. Để đơn giản và tránh bị lỗi trong chương trình, giải pháp tối ưu là biên tập lại file dữ liệu thành dạng chuẩn để LandCadViet Utility nhận được, điều này không có gì khó đối với các surveyer. SSg có thể tham khảo bài viết của ElleHCSC ngày 23/01/2008 cũng ở toppic này
  • 0

#69 tnmtpc

tnmtpc

    biết dimcontinue

  • Members
  • PipPipPipPipPip
  • 370 Bài viết
Điểm đánh giá: 206 (khá)

Đã gửi 24 March 2008 - 10:50 AM

Bác có thể mô phỏng trên FreeMind không???
Như thế đọc đỡ mệt hơn mà ý nghĩa trình bày rõ ràng hơn.

FreeMind! chà, mình chưa "cập nhật" được, đại loại ý tưởng là thế này: từ file dữ liệu chuẩn, LandCadViet Utility import data để trở thành bản vẽ "thô" có các thông tin: chấm điểm (point), tên điểm, cao độ (đối với bản vẽ địa hình), code, ghi chú, mỗi đối tượng trên một layer riêng. Kết thúc quá trình chuyển giao dữ liệu, tiếp theo thực hiện xử lý code để chèn đối tượng symbol và nối điểm
  • 0

#70 ssg

ssg

    biết lệnh adcenter

  • Vip
  • PipPipPipPipPipPipPip
  • 1228 Bài viết
Điểm đánh giá: 1087 (rất tốt)

Đã gửi 24 March 2008 - 02:27 PM

Các bạn xem thử cái này và cho ý kiến đóng góp:
http://www.cadviet.c..._Package_01.zip
Unzip và đọc readme
  • 0

#71 ssg

ssg

    biết lệnh adcenter

  • Vip
  • PipPipPipPipPipPipPip
  • 1228 Bài viết
Điểm đánh giá: 1087 (rất tốt)

Đã gửi 25 March 2008 - 09:39 AM

Mình đọc lại bài này của anh Hoành, đã giải quyết được vấn đề dấu chấm thập phân của text Caodo trùng hoàn toàn với point. Một thủ thuật tuyệt vời! Cám ơn anh Hoành!
http://www.cadviet.c...o...
  • 0

#72 tnmtpc

tnmtpc

    biết dimcontinue

  • Members
  • PipPipPipPipPip
  • 370 Bài viết
Điểm đánh giá: 206 (khá)

Đã gửi 25 March 2008 - 08:10 PM

Các bạn xem thử cái này và cho ý kiến đóng góp:
http://www.cadviet.com/upfiles/LCV_Package_01.zip
Unzip và đọc readme

đối với file*.csv có đầy đủ "các thành phần" thì OK, còn các dạng file khác thì "bó tay chấm com". Để có cơ sở SSg nghiên cứu, mình gửi một số file "nguyên mẫu", đối với file BAIRAC.dat chỉ có 3 trường "Northing","Easting","Elevation", đối với file SL20.asc không có tiêu đề các trường nhưng thứ tự của chúng là "tendiem,X,Y,Z", còn file Bdo500.idx thì quá ư phức tạp, có nhiều "thông tin gây nhiễu" cho LandCadViet Utility, trong file này dữ liệu chính bắt đầu từ dòng:
DATABASE
POINTS(PointNo, PointID, East, North, Elevation, Code, Date, CLASS)
đến dòng THEMINFO(PointNo, PointID, Attribute, Value)
Với loại file dữ liệu này chỉ có chương trình chuyên biệt của nó mới đọc được
Nói tóm lại, LandCadViet Utility sẽ chỉ nhận được một số định dạng chuẩn nào đó, na ná như *.csv chẳng hạn, anh nào muốn chơi với Cad bằng con đường LandCadViet Utility thì chịu khó edit file dữ liệu thành dạng chuẩn để giao tiếp, SSg cố gắng test một số dạng file và khuyến cáo người dùng về các dạng file đó
Về dấu "," trong code thay bằng ký tự j thì không thành vấn đề, vì code do người sử dụng nhập
Về vị trí các text, giải quyết được vấn đề dấu chấm thập phân trùng với point là "đúng bài", còn các text khác theo mình tên điểm cho nằm trên text cao độ
Tuy mới chạy thử " bản nháp rất sơ khai" nhưng mình thấy ưng cái bụng lắm! Chúc SSg và các bạn sức khỏe dồi dào để tham gia diễn đàn Cadviet rầm rộ hơn, còn đây là các file mình gửi kèm để tham khảo
http://www.cadviet.c...es/file_mau.rar
  • 0

#73 ssg

ssg

    biết lệnh adcenter

  • Vip
  • PipPipPipPipPipPipPip
  • 1228 Bài viết
Điểm đánh giá: 1087 (rất tốt)

Đã gửi 26 March 2008 - 08:51 AM

đối với file*.csv có đầy đủ "các thành phần" thì OK, còn các dạng file khác thì "bó tay chấm com". Để có cơ sở SSg nghiên cứu, mình gửi một số file "nguyên mẫu", đối với file BAIRAC.dat chỉ có 3 trường "Northing","Easting","Elevation", đối với file SL20.asc không có tiêu đề các trường nhưng thứ tự của chúng là "tendiem,X,Y,Z", còn file Bdo500.idx thì quá ư phức tạp, có nhiều "thông tin gây nhiễu" cho LandCadViet Utility, trong file này dữ liệu chính bắt đầu từ dòng:
DATABASE
POINTS(PointNo, PointID, East, North, Elevation, Code, Date, CLASS)
đến dòng THEMINFO(PointNo, PointID, Attribute, Value)
Với loại file dữ liệu này chỉ có chương trình chuyên biệt của nó mới đọc được
Nói tóm lại, LandCadViet Utility sẽ chỉ nhận được một số định dạng chuẩn nào đó, na ná như *.csv chẳng hạn, anh nào muốn chơi với Cad bằng con đường LandCadViet Utility thì chịu khó edit file dữ liệu thành dạng chuẩn để giao tiếp, SSg cố gắng test một số dạng file và khuyến cáo người dùng về các dạng file đó
Về dấu "," trong code thay bằng ký tự j thì không thành vấn đề, vì code do người sử dụng nhập
Về vị trí các text, giải quyết được vấn đề dấu chấm thập phân trùng với point là "đúng bài", còn các text khác theo mình tên điểm cho nằm trên text cao độ
Tuy mới chạy thử " bản nháp rất sơ khai" nhưng mình thấy ưng cái bụng lắm! Chúc SSg và các bạn sức khỏe dồi dào để tham gia diễn đàn Cadviet rầm rộ hơn, còn đây là các file mình gửi kèm để tham khảo
http://www.cadviet.c...es/file_mau.rar

OK, đọc các file bạn gởi, mình hiểu thêm rất nhiều. Nhưng còn dạng nào nữa, bạn tổng hợp lại và gởi luôn đi, càng sớm càng tốt. Mình đã đọc bài của elleHCSC rồi, nói chung là cũng hiểu, nhưng có file nguyên mẫu như bạn vừa gởi là tốt nhất. Tự thân chúng có những cái, theo user thì chẳng là gì nhưng với programmer thì cực kỳ quan trọng.
Tư duy lập trình rất đơn giản: Input -> Processing -> Output
Cái Input không đầy đủ thì chưa thể có tư duy đúng và đương nhiên là không thể có chương trình!
Các vấn đề khác hoàn toàn nhất trí với bạn, kể cả vị trí Tendiem nằm trên text Caodo. Nhưng xin hỏi lại, nếu người dùng không chọn "Su dung so lieu Z", text caodo không có thỉ text Tendiem nằm ở đâu? Có phải là đúng ngay vị trí point?
  • 0

#74 tnmtpc

tnmtpc

    biết dimcontinue

  • Members
  • PipPipPipPipPip
  • 370 Bài viết
Điểm đánh giá: 206 (khá)

Đã gửi 26 March 2008 - 10:31 AM

OK, đọc các file bạn gởi, mình hiểu thêm rất nhiều. Nhưng còn dạng nào nữa, bạn tổng hợp lại và gởi luôn đi, càng sớm càng tốt. Mình đã đọc bài của elleHCSC rồi, nói chung là cũng hiểu, nhưng có file nguyên mẫu như bạn vừa gởi là tốt nhất. Tự thân chúng có những cái, theo user thì chẳng là gì nhưng với programmer thì cực kỳ quan trọng.
Tư duy lập trình rất đơn giản: Input -> Processing -> Output
Cái Input không đầy đủ thì chưa thể có tư duy đúng và đương nhiên là không thể có chương trình!
Các vấn đề khác hoàn toàn nhất trí với bạn, kể cả vị trí Tendiem nằm trên text Caodo. Nhưng xin hỏi lại, nếu người dùng không chọn "Su dung so lieu Z", text caodo không có thỉ text Tendiem nằm ở đâu? Có phải là đúng ngay vị trí point?

trong bản chạy thử, khi không sử dụng giá trị Z, point có giá trị Z=0 nhưng text cao độ vẫn hiển thị, mình tính góp ý là không cho hiển thị text giá trị cao độ, nhưng nghĩ lại cũng không cần thiết vì chỉ cần tắt lớp caodo là xong, khi nào cần tham khảo thì mở nó ra. Vị trí các text là mặc định trong mọi trường hợp
  • 0

#75 elleHCSC

elleHCSC

    biết lệnh copy

  • Members
  • PipPipPip
  • 119 Bài viết
Điểm đánh giá: 98 (tàm tạm)

Đã gửi 26 March 2008 - 05:35 PM

OK, đọc các file bạn gởi, mình hiểu thêm rất nhiều. Nhưng còn dạng nào nữa, bạn tổng hợp lại và gởi luôn đi, càng sớm càng tốt. Mình đã đọc bài của elleHCSC rồi, nói chung là cũng hiểu, nhưng có file nguyên mẫu như bạn vừa gởi là tốt nhất. Tự thân chúng có những cái, theo user thì chẳng là gì nhưng với programmer thì cực kỳ quan trọng.
Tư duy lập trình rất đơn giản: Input -> Processing -> Output
Cái Input không đầy đủ thì chưa thể có tư duy đúng và đương nhiên là không thể có chương trình!
Các vấn đề khác hoàn toàn nhất trí với bạn, kể cả vị trí Tendiem nằm trên text Caodo. Nhưng xin hỏi lại, nếu người dùng không chọn "Su dung so lieu Z", text caodo không có thỉ text Tendiem nằm ở đâu? Có phải là đúng ngay vị trí point?


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.
  • 0
Share for all, all will share !

--------------------
HTTP://WWW.HCSC.VN
HTTP://WWW.HCSC.COM.VN

#76 ssg

ssg

    biết lệnh adcenter

  • Vip
  • PipPipPipPipPipPipPip
  • 1228 Bài viết
Điểm đánh giá: 1087 (rất tốt)

Đã gửi 27 March 2008 - 10:34 AM

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.
  • 0

#77 tnmtpc

tnmtpc

    biết dimcontinue

  • Members
  • PipPipPipPipPip
  • 370 Bài viết
Điểm đánh giá: 206 (khá)

Đã gửi 27 March 2008 - 11:06 AM

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
  • 0

#78 elleHCSC

elleHCSC

    biết lệnh copy

  • Members
  • PipPipPip
  • 119 Bài viết
Điểm đánh giá: 98 (tàm tạm)

Đã gửi 27 March 2008 - 02:12 PM

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.c...pfiles/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:
  • 0
Share for all, all will share !

--------------------
HTTP://WWW.HCSC.VN
HTTP://WWW.HCSC.COM.VN

#79 tnmtpc

tnmtpc

    biết dimcontinue

  • Members
  • PipPipPipPipPip
  • 370 Bài viết
Điểm đánh giá: 206 (khá)

Đã gửi 27 March 2008 - 03:09 PM

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
  • 0

#80 ssg

ssg

    biết lệnh adcenter

  • Vip
  • PipPipPipPipPipPipPip
  • 1228 Bài viết
Điểm đánh giá: 1087 (rất tốt)

Đã gửi 27 March 2008 - 04:58 PM

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.c...les/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.
  • 0