Chuyển đến nội dung
Diễn đàn CADViet
  • Thông báo

    • Nguyen Hoanh

      CADViet đã hoàn tất nâng cấp   14/09/2017

      Chào các bạn, CADViet đã hoàn tất việc nâng cấp lên phiên bản mới. Tất cả các chức năng đã hoạt động theo kỳ vọng của ban quản trị. Nếu có vấn đề gì cần phản hồi, các bản post ở đây nhé: Trân trọng, Nguyễn Hoành.
ssg

LandCadViet Utility

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

Bác cài thêm Java nhé

 

https://sdlc1e.sun.com/ECom/EComActionServl...4FC43EF7109A067

 

Bản này nè

 

Windows Offline Installation, Multi-language

Đã vào đường dẫn trên, thấy 1 rừng java.

Nhưng vẫn chưa tìm đc bản java như trên (Windows Offline Installation, Multi-language)

Bác ssg hoặc vndesperados có thể up file cài đặt cho java luôn đc kg?

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ào đường dẫn trên, thấy 1 rừng java.

Nhưng vẫn chưa tìm đc bản java như trên (Windows Offline Installation, Multi-language)

Bác ssg hoặc vndesperados có thể up file cài đặt cho java luôn đc kg?

File java >70MB, up lên chắc cháy Server của CADVIET mất

 

Download here

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 nêu một vấn đề quan trọng đầu tiên, liên quan đến việc xây dựng chương trình LandCadViet....

Công việc trước tiên chương trình phải làm là đọc được các số liệu do người dùng cung cấp, ở nhiều định dạng file khác nhau, hiểu chúng một cách chính xác và convert toàn bộ chúng sang dữ liệu kiểu list (là kiểu dữ liệu cơ bản của ngôn ngữ lisp). Khi đã xong động tác này, chương trình lisp có thể dễ dàng làm mọi chuyện khác theo ý thích của người dùng (ngôn ngữ Lisp cung cấp rất nhiều hàm thao tác với dữ liệu kiểu list)

Để làm được việc trên, có mấy vấn đề cần phân tích kỹ....

 

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

 

Các bạn unzip và đọc file *.doc

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 nêu một vấn đề quan trọng đầu tiên, liên quan đến việc xây dựng chương trình LandCadViet....

Trước tiên là cám ơn ban Ssg đã rất tâm huyết với mục tiêu đã đặt ra cho LCV.

Sau khi xem bài viết của bạn tôi có mấy ý kiến sau:

1-Các trường trong ví dụ .xls là đúng yêu cầu không cần thêm bớt gì cả.

2-Các dòng từ A1-A3 khi lập trình nên viết 1 hàm đọc riêng 3 dòng này và lưu vào 1 biến riêng vd biến header

3-Dòng ghi chú cuối cùng nên khuyến cáo người dùng ghi luôn sau dòng có Hm = xxx

4-Các dòng từ A4-A9 là các data chủ yếu cần cho công việc. Đây mới là nguồn data để kiến tạo bản vẽ địa hình.

5-Khi lập trình nên viết các hàm tùy chọn lọc lựa các ký tự ACCI ngăn cách như: Space, Tab, Comma, các ký hiệu khác như ":"

6-Nên đưa 1 hộp thoại cho người dùng xem và kiểm tra lại các trường số liệu trước khi thực thi lệnh Acad.

7-Khi chạy và vẽ nên tạo ra Block thuộc tính, và chỉ ghi ra bản vẽ 4 trường tendiem, Z, Code và ghi chú. Sau này có các lệnh nối các

điểm theo tên, theo Cdoe và theo ghi chú.

8-Dĩ nhiên chương trình phải có 1 bảng hướng dẫn dạng thông báo rõ ràng các quy ước đọc dữ liệu cho người dùng.Hoặc viết thành Help (tốn thì giờ lắm đó)

Tôi tin chắc là bạn SSg sẽ làm nên chuyện lớn chứ ko nhỏ hề hề.

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 nêu một vấn đề quan trọng đầu tiên, liên quan đến việc xây dựng chương trình LandCadViet....

Công việc trước tiên chương trình phải làm là đọc được các số liệu do người dùng cung cấp, ở nhiều định dạng file khác nhau, hiểu chúng một cách chính xác và convert toàn bộ chúng sang dữ liệu kiểu list (là kiểu dữ liệu cơ bản của ngôn ngữ lisp). Khi đã xong động tác này, chương trình lisp có thể dễ dàng làm mọi chuyện khác theo ý thích của người dùng (ngôn ngữ Lisp cung cấp rất nhiều hàm thao tác với dữ liệu kiểu list)

Để làm được việc trên, có mấy vấn đề cần phân tích kỹ....

 

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

 

Các bạn unzip và đọc file *.doc

Trước hết, sorry Bác SSg vì có một sự nhầm lẫn. đó là: ý của TNMTPC, file VD1 không phải là file dữ liệu chuẩn để trao đổi với Cad. Hai file *xls trước đây TNMTPC up lên diễn đàn là với mục đích để SSg có "khái niệm" của việc đo và xử lý nội nghiệp khảo sát (vì trước đó SSg có yêu cầu anh em trắc địa cung cấp những thông tin về trắc địa, từ lúc vác máy đi ngắm đến khi ra được bản đồ...), do vậy hai file trên mục đích diễn giải quan hệ tính toán số liệu thô với kết quả xử lý nội nghiệp khảo sát. nên có những thông tin "gây nhiễu" trong file. lần nữa I'm sorry!

tóm lại, file dữ liệu để cho anh cad "xơi" có dòng đầu tiên là tiêu đề của các trường. từ dòng 2 trở đi là dữ liệu để convert. Ngoài ra không còn thông tin nào khác. Vậy thì các file tính toán (ví dụ 1. XLS), các suveyer phải làm "sạch" thành file chuẩn (việc này quá đơn giản) trước khi chuyển sang cad.

Về định dạng file: dữ liệu trong một record tuân thủ chặc chẽ, được phân cách với nhau bằng một dấu hiệu xác định. Còn các dạng file khác (XYH, TAB...) là file tạo ra do thiết bị đo xuất ra hoặc từ một chưng trình tính toán khác, có thể không đầy đủ các trường nhưng trường tendiem, x, y, z, code thì không thể thiếu. Vậy thì trong listbox của tùy chon trường có thêm tùy chọn none.

Như vậy trên mind map đã giải quyết xong hai dấu ? Còn tùy chọn thứ tự các trường phải giải quyết bằng được vì bảng dữ liệu của mỗi người sẽ có khác về thứ tự các trường.

Về modul địa hình đúng là "ớn ăn" có lẽ để nghiên cứu sau vây.

Thay mặt anh em trắc địa cảm ơn SSg vì sự nhiệt tình này; Bái phục bái phụ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
Trước hết, sorry Bác SSg vì có một sự nhầm lẫn. đó là: ý của TNMTPC, file VD1 không phải là file dữ liệu chuẩn để trao đổi với Cad. Hai file *xls trước đây TNMTPC up lên diễn đàn là với mục đích để SSg có "khái niệm" của việc đo và xử lý nội nghiệp khảo sát (vì trước đó SSg có yêu cầu anh em trắc địa cung cấp những thông tin về trắc địa, từ lúc vác máy đi ngắm đến khi ra được bản đồ...), do vậy hai file trên mục đích diễn giải quan hệ tính toán số liệu thô với kết quả xử lý nội nghiệp khảo sát. nên có những thông tin "gây nhiễu" trong file. lần nữa I'm sorry!

tóm lại, file dữ liệu để cho anh cad "xơi" có dòng đầu tiên là tiêu đề của các trường. từ dòng 2 trở đi là dữ liệu để convert. Ngoài ra không còn thông tin nào khác. Vậy thì các file tính toán (ví dụ 1. XLS), các suveyer phải làm "sạch" thành file chuẩn (việc này quá đơn giản) trước khi chuyển sang cad.

Về định dạng file: dữ liệu trong một record tuân thủ chặc chẽ, được phân cách với nhau bằng một dấu hiệu xác định. Còn các dạng file khác (XYH, TAB...) là file tạo ra do thiết bị đo xuất ra hoặc từ một chưng trình tính toán khác, có thể không đầy đủ các trường nhưng trường tendiem, x, y, z, code thì không thể thiếu. Vậy thì trong listbox của tùy chon trường có thêm tùy chọn none.

Như vậy trên mind map đã giải quyết xong hai dấu ? Còn tùy chọn thứ tự các trường phải giải quyết bằng được vì bảng dữ liệu của mỗi người sẽ có khác về thứ tự các trường.

Về modul địa hình đúng là "ớn ăn" có lẽ để nghiên cứu sau vây.

Thay mặt anh em trắc địa cảm ơn SSg vì sự nhiệt tình này; Bái phục bái phục!

OK, cái nhìn của chuyên môn và lập trình đã gần nhau hơn. Nhưng hình như bạn vẫn chưa hiểu hết ý, bạn cần giúp mình một việc nữa:

Bỏ tất cả những file ví dụ bạn đã post hôm nọ đi, không quan tâm nữa. Bạn biên tập lại toàn bộ chúng các theo tiêu chí: điển hinh, chính xác, không thiều, không thừa. Nếu cần thuyết minh gì thêm thì ghi riêng vào 1 file *.doc, đừng "gây nhiễu" cho các file ví dụ mẫu. Cụ thể là:

A- Đầu vào:

- Các file dữ liệu: mỗi loại (như đã phân tích) phải có 1 file

- Thư viện chứa các block địa vật (chỉ cần những cái có sử dụng trong ví dụ)

B- Đầu ra:

(chỉ cần lấy file *.csv làm mẫu, các dạng khác ssg tự suy ra)

- Bản vẽ địa hình: được tạo thành từ những số liệu trong file *.csv trên

- Bản vẽ địa chính: như trên

- Bản vẽ hồ sơ kỹ thuật thửa đất, lấy từ 1 thửa cụ thể nào đó có trong bản vẽ địa chính trên. Đừng lấy một bản lạ hoắc nào ở đâu đó, ssg không biết đường nào mà lần!

 

Có 2 lý do quan trọng:

1) Rất nhiều cái, có thể các bạn trong ngành cho là đơn giản, là đương nhiên, nhưng với ssg thì có khi rất mơ hồ! Các file ví dụ, với những con số cụ thể, chính xác, tự thân nó sẽ nói lên nhiều điều, không cần giải thích dài dòng.

2) Trước khi "trình làng", bản thân người lập trình phải thực hiện không biết bao nhiêu lần cái vòng lặp "Lập trình - Test - Chỉnh sửa - Test lại - Sửa lại....". Còn mơ hồ về kết quả đúng thì lấy gì để đối chiếu khi test?!

Bạn cho số liệu đầu vào là A, yêu cầu chương trình xử lý để nhận được kết quả là B.

Khi test chương trình được kết quả là B1. Nếu B1 đồng nhất hoàn toàn với B, không có bất cứ một sự khác biệt nào dù là nhỏ nhất, thì mới có thể tạm coi như chương trình chạy đúng.

Mong rằng bạn hiểu ý. Mình chờ phản hồi của bạn.

  • 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ác bạn xem và góp ý cho cái này:

 

form1.jpg

 

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.

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ác bạn xem và góp ý cho cái này:

 

form1.jpg

 

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.

 

 

Theo mình nghĩ trong file dữ liệu ta dùng header hay hơn bác ssg ah.

khi đọc dữ liệu tùy theo header ta sẽ có fields tương ứng.

Mặc khác thứ tự XYZ là chuẩn rồi, vì có lẽ chẳng ai sáng tạo ra kiểu ghi toa độ là ZYX hay là YZX đâu.

Như vậy thì giao diên cũng gọn hơn mà người dùng cũng không phải băn khoăn việc thứ tự fields

Có thể tạo thêm một child dialog để xem trước qua file dữ liệu, đơn giản chỉ là một multitextbox để xem dữ liệu thôi.(Có thể chỉnh sửa luôn thì tốt - cái này thì tôi làm OK)

Tao thêm một button là Option - các thao tác về thiết đinh (Layer, style...) sẽ làm trên một dialog khác

Việc chọn layer có thêm phần default...

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

Wow pro rồi đó bác SSG à. Trước tới giờ chưa có hình anh cụ thể nên mọi người diễn giải với nhau khó quá. Tôi xin đóng góp một số ý kiến như sau:

 

1.

Có thể tạo thêm một child dialog để xem trước qua file dữ liệu, đơn giản chỉ là một multitextbox để xem dữ liệu thôi.

OK rất đồng ý với VN... vì khi view được số liệu thì user sẽ biết được phải import theo thứ tự field nào cho chính xác

 

2. Mục thứ tự các field tại popup_list tai field Z, Code, Ghichu ta thêm vào mỗi Field một list nữa là "None" để đề phòng một số trường hợp các file số liệu cũ của ai đó chỉ có 3 field là Tendiem, X, Y. Nghĩa là cứ có tối thiểu 3 yếu tố cơ bản trên là ta có thế "bắn" điểm vào CAD được rồi.

 

3. Ứng với mỗi field khi được chọn (nghĩa là khác None) thì "Layer cho cac yeu to" tương ứng sẽ "sáng" luôn (Enable) còn không thì cho "Disble" khỏi mất công chọn nữa. Quan điểm của tôi là càng đơn giản được thao tác càng tốt vì mục đính của chương trình là bắn điểm vào cad nhưng cũng tạo 1 thói quen "chuẩn hoá" cho user.

 

4. Theo tôi tên của các Layer SSG cho fix cố định luôn nếu trong bản vẽ chưa có, mục đính để thống nhất chuẩn hoá vì bản thân cái tên layer đã thể hiện được nó là cái gì rồi. Chúng ta nên tránh một nhược điểm lớn nhất của file vẽ bản đồ là sự không thống nhất tên các layer. Năm 96, 97 gì đó Tổng cục Địa chính đã phải rất vất vả và cũng phải mất rất nhiều công sức, tiền của để làm một dự án chuẩn hoá bản đồ số mà sản phẩm của nó là một bộ chương trình FAMIS, CADBD hiện tại đang dùng trong ngàngh đo đạc. Đáng tiếc nó là 1 phần mềm chạy trên MicroStation chứ không phải trên nền AutoCad, nếu cần tôi sẽ upload lên cho các bạn tham khảo.

 

5. Ngoài mục "Chieu cao text cao do" ta cho thêm vào 1 mục nữa là "Chieu cao text Tendiem" có tác dụng tương tự như của mục cao độ để user chọn (do bản đồ có thể làm cho nhiều tỷ lệ nên cần cái này).

 

6. Phải có logo như SSG nói chứ ! Nào CADVIET man đâu roài, rất nhiều KTS đó hãy làm cho LCVU 1 cái cho hoàng tráng nhá (món thiết kế là tôi chịu rồi - Cadastral Surveyer mà)

  • Vote tăng 2

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ác bạn xem và góp ý cho cái này:

 

form1.jpg

 

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...)

  • Vote giảm 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 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.

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

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

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 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.com/upfiles/LandCadViet_Utility.rar

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

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

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

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

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

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.com/forum/index.php?sho...entry5163

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á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.com/upfiles/file_mau.rar

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
đố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.com/upfiles/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?

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

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

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


×