Tìm đoạn thẳng gần điểm nhất

[tdvn 53]

Chào các bạn cadviet. Có lẽ mình ðến với diễn ðàn này hõi trễ nên có những cái mình cứ loay hoay mãi. Hôm nay mình mạnh dạn ðề xuất thêm một chủ ðề nữa (sau chủ ðề "tìm vị trí trống nhất trong ða giác"), cũng là chủ ðề làm mình mất ãn mất ngủ. Chủ ðề nghe rất quen thuộc nhýng cũng rất khó (ðối với mình). Ðó là chủ ðề "Tìm ðoạn thẳng gần ðiểm nhất".

Các bạn thấy ðấy, trong các phần mềm bản ðồ và cả trong cad, khi tính diện tích bạn Pick vào một ðiểm, chýõng trình sẽ tìm ðoạn thẳng gần ðiểm nhất và sau ðó sẽ tìm ðýờng bao. Hay các kiểu bắt ðiểm trong cad tôi nghĩ cũng theo cõ chế này. Theo suy nghĩ thông thýờng thì ta lập vòng lặp ði qua tất cả các ðoạn thẳng và tìm khoảng cách ngắn nhất từ ðiểm ðến ðoạn thẳng hay ðến hai ðầu ðoạn thẳng. Nhýng trong bản vẽ có vô số ðoạn thẳng (vài trãm ngàn hoặc hõn) và dài ngắn khác nhau nên thời gian lặp là rất lâu. Nếu sử dụng lệnh chọn ðối týợng theo hình vuông lớn dần có tâm là ðiểm trên ðể hạn chế số lýợng ðoạn thẳng cũng không tiện vì cad chỉ chọn các ðối týợng có trên màn hình. Hiện nay mình cũng ðang dùng tạm kiểu này, cứ mỗi lần nhý vậy phải ðýa ðiểm ðến tâm màn hình làm cho nó cứ pan liên hồi

Có thể ðây là bài toán cãn bản của ngành lập trình nhýng mình không phải là dân công nghệ thông tin chính quy nên mình cũng không biết ðã có giải thuật này hay chýa. Bạn nào có ý týởng hay thì giải giúp mình nhé.

[ssg 1104]

Chào các bạn cadviet. Có lẽ mình ðến với diễn ðàn này hõi trễ nên có những cái mình cứ loay hoay mãi. Hôm nay mình mạnh dạn ðề xuất thêm một chủ ðề nữa (sau chủ ðề "tìm vị trí trống nhất trong ða giác"), cũng là chủ ðề làm mình mất ãn mất ngủ. Chủ ðề nghe rất quen thuộc nhýng cũng rất khó (ðối với mình). Ðó là chủ ðề "Tìm ðoạn thẳng gần ðiểm nhất".

Các bạn thấy ðấy, trong các phần mềm bản ðồ và cả trong cad, khi tính diện tích bạn Pick vào một ðiểm, chýõng trình sẽ tìm ðoạn thẳng gần ðiểm nhất và sau ðó sẽ tìm ðýờng bao. Hay các kiểu bắt ðiểm trong cad tôi nghĩ cũng theo cõ chế này. Theo suy nghĩ thông thýờng thì ta lập vòng lặp ði qua tất cả các ðoạn thẳng và tìm khoảng cách ngắn nhất từ ðiểm ðến ðoạn thẳng hay ðến hai ðầu ðoạn thẳng. Nhýng trong bản vẽ có vô số ðoạn thẳng (vài trãm ngàn hoặc hõn) và dài ngắn khác nhau nên thời gian lặp là rất lâu. Nếu sử dụng lệnh chọn ðối týợng theo hình vuông lớn dần có tâm là ðiểm trên ðể hạn chế số lýợng ðoạn thẳng cũng không tiện vì cad chỉ chọn các ðối týợng có trên màn hình. Hiện nay mình cũng ðang dùng tạm kiểu này, cứ mỗi lần nhý vậy phải ðýa ðiểm ðến tâm màn hình làm cho nó cứ pan liên hồi

Có thể ðây là bài toán cãn bản của ngành lập trình nhýng mình không phải là dân công nghệ thông tin chính quy nên mình cũng không biết ðã có giải thuật này hay chýa. Bạn nào có ý týởng hay thì giải giúp mình nhé.

1. Chưa hiểu ý bạn lắm, đặc biệt là đoạn đánh dấu đỏ.

2. Khoảng cách ngắn nhất từ điểm p đến curve: (vlax-curve-getClosestPointTo curve p)

3. ssget với tuỳ chọn "w" hoặc "c" cho phép chọn các đối tượng trong một cửa sổ xác định. Đúng là phải "nhìn thấy" trên màn hình, nhưng khi chương trình đã chạy, tại sao không cho nó zoom all?

[tdvn 53]

1. Chưa hiểu ý bạn lắm, đặc biệt là đoạn đánh dấu đỏ.

2. Khoảng cách ngắn nhất từ điểm p đến curve: (vlax-curve-getClosestPointTo curve p)

3. ssget với tuỳ chọn "w" hoặc "c" cho phép chọn các đối tượng trong một cửa sổ xác định. Đúng là phải "nhìn thấy" trên màn hình, nhưng khi chương trình đã chạy, tại sao không cho nó zoom all?

Nói chung bài toán của mình có thể hình dung như vậy. Bạn có vài trăm ngàn line dài ngắn khác nhau bất kỳ trong cad hay trong một csdl. Bạn cung cấp một điểm bất kỳ trong đó. Hãy lấy ra đoạn thẳng gần điểm đó nhất.

 

1. Lúc đầu mình cho cửa sổ có giá trị xác định, nhưng nếu không chọn được đối tượng nào thì cho nó lớn dần lên cho đến khi có đối tượng trong đó thì thôi.

2. Lâu nay mình không nghiên cứu thêm những hàm của vl nên mình chưa hiểu lắm. Mình sẽ tìm hiểu thêm.

3. Thường bản vẽ có diện tích rất lớn (vài trăm ha) và rất nhiều đối tượng (vài trăm ngàn), việc zoom all làm kín màn hình và lảm giảm độ chính xác hàm ssget với tùy chọn "w", "c" ... và hàm ssget trong trường hợp có nhiều đối tượng trên màn hình cũng diễn ra rất chậm. Mình cũng có khả năng lập trình được (tuy nhiên vẫn là nghiệp dư, chỉ say mê thế thôi, làm cho công việc của mình nhanh hơn là thích rồi) nhưng những ý tưởng hiện nay của mình không tối ưu lắm. Mình cần một cơ sở lý thuết hoặc một ý tưởng hay hơn, nếu các bạn biết xin mách giúp.

[ssg 1104]

Nói chung bài toán của mình có thể hình dung như vậy. Bạn có vài trăm ngàn line dài ngắn khác nhau bất kỳ trong cad hay trong một csdl. Bạn cung cấp một điểm bất kỳ trong đó. Hãy lấy ra đoạn thẳng gần điểm đó nhất.

 

1. Lúc đầu mình cho cửa sổ có giá trị xác định, nhưng nếu không chọn được đối tượng nào thì cho nó lớn dần lên cho đến khi có đối tượng trong đó thì thôi.

2. Lâu nay mình không nghiên cứu thêm những hàm của vl nên mình chưa hiểu lắm. Mình sẽ tìm hiểu thêm.

3. Thường bản vẽ có diện tích rất lớn (vài trăm ha) và rất nhiều đối tượng (vài trăm ngàn), việc zoom all làm kín màn hình và lảm giảm độ chính xác hàm ssget với tùy chọn "w", "c" ... và hàm ssget trong trường hợp có nhiều đối tượng trên màn hình cũng diễn ra rất chậm. Mình cũng có khả năng lập trình được (tuy nhiên vẫn là nghiệp dư, chỉ say mê thế thôi, làm cho công việc của mình nhanh hơn là thích rồi) nhưng những ý tưởng hiện nay của mình không tối ưu lắm. Mình cần một cơ sở lý thuết hoặc một ý tưởng hay hơn, nếu các bạn biết xin mách giúp.

Khi số lượng đối tượng khá lớn, vấn đề tốc độ xử lý đúng là phải được quan tâm một cách thích đáng. Nói về IT, bản thân ssg và có lẽ đa số dân CadViet đều có bằng... LBP - Learn by Bits and Pieces - "diễn nôm" theo cách nói của bạn phamthanhbinh là... "học mót"! Bởi vậy, luận bàn về "cơ sở lý thuyết" thì chẳng dám, ssg chỉ dựa vào các bits và pieces nhặt nhạnh được, xin có vài ý kiến như sau:

Công việc bạn cần không thể thiếu các bước:

1. Tập hợp đối tượng

2. Xác định khoảng cách ngắn từ điểm đã cho đến từng đối tượng

3. So sánh và chọn ra khoảng cách ngắn nhất

 

Bước 2: dùng (vlax-curve-getClosestPointTo curve p) không chê vào đâu được. Bạn cứ thử khắc biết!

Bước 3: ssg cũng có đọc qua lý luận về phép so sánh, không có một thủ thuật nào có thể so sánh cùng lúc hơn 2 đối tượng với nhau. Nếu có n đối tượng, số lượng các phép so sánh phải là n-1, bất kể bạn dùng kiểu gì.

Chính vì lý do nêu lên ở bước 3, yếu tố quyết định cho tốc độ chung của cả quá trình nằm ở bước 1, phải khoanh vùng đối tượng (giống như cảnh sát điều tra truy tìm tội phạm giữa biển người mênh mông vậy mà!). Khoanh vùng như thế nào thì tuỳ trường hợp cụ thể. Cách làm của bạn là một hướng khả dĩ.

 

Về ssget, tốc độ cũng không đến nỗi nào. Ssg đã thử gọi ssget với khoảng 100000 đối tượng (bản vẽ khoảng 5MB), kết quả hầu như có ngay tức khắc. Khi gọi ssget, nên tận dụng tối đa các bộ lọc, kể cả các Logical Filter (AND, OR).

Ngoài ra, sử dụng các functions VL cũng góp phần tăng tốc độ xử lý. VL sử dụng kỹ thuật ActiveX Automation, ngoài khả năng tương tác và giao tiếp được với nhiều môi trường, nhiều ứng dụng khác nhau, nói chung là chúng chạy nhanh hơn các functions AutoLisp truyền thống.

Trích Help:

ActiveX Automation is a new way to work programmatically with the contents of an AutoCAD drawing. In many instances, ActiveX works faster than traditional AutoLISP functions in manipulating AutoCAD drawing objects.

The ActiveX programming interface is usable from a number of languages and environments, such as C++, Visual BasicTM, and DelphiTM. When you work with ActiveX objects in AutoLISP, you work with the same object model, properties, and methods that can be manipulated from other programming environments.

Chúc bạn thành công!

[Nguyen Hoanh 4669]

Đây không phải là bài toán khó về thuật toán. Nó khó về mức độ tối ưu của thời gian thực thi.

 

Theo thiển ý của mình, Tdvn nên upload 1 file mà theo bạn là 'nặng' với đoạn code bạn đã làm.

 

Mọi người sẽ giúp bạn bằng cách tìm ra code tối ưu hơn code của bạn trong trường hợp file của bạn.

[tdvn 53]

Chào bác Nguyen Hoanh và bác ssg. Cám ơn các bạn đã bỏ thời gian suy nghĩ cái bài toán của mình.

Cái ý tưởng khoanh vùng mình cũng có nghĩ tới nhưng khoanh như thế nào cho tối ưu thì mình chưa nghĩ ra

Do cái lệnh tính diện tích tự động của cad không có và thường phải thông qua lệnh tạo polyline và không phải lúc nào cũng thành công nhất là đối với hệ thống giao thông thủy hệ dài dằng dặc trên bản đồ nên mình dự định viết cái chương trình quản lý line và tính diện tích riêng. Công việc của mình thường dùng hàng loạt lệnh tính và tìm đường bao và nhiều xử lý khác nữa trên dữ liệu lớn. Nếu zoom all làm việc xử lý chậm và một số lần chọn dt thông qua (ssget "w", "c", "cp" ...) kém chính xác còn nếu tầm nhìn lớn thì phải zoom, pan liên tục cho điểm chọn và các đối tượng liên quan (thường mình không biết trước đối tượng nào sẽ được chọn) nằm trên màn hình nên cũng bất tiện. Code đoạn này mình viết trên Delphi và VisualC++ (vẫn sd hàm ssget của cad) nếu UP lên đây e lạc đề mất.

Có thể nói gọn lại là mình muốn viết cái hàm kiểu như ssget chọn đối tượng thông qua của sổ bất kỳ nhưng không hẳn phải nhìn thấy trên màn hình, từ đó tìm ra đoạn thẳng gần điểm nhất để làm nơi xuất phát tìm đường bao, tính diện tích .... Nếu các bạn có ý tưởng hay thì mách nước cho mình

[elleHCSC 98]

Tôi cũng làm bản đồ bằng cad và cũng có các file vẽ "cực to" cỡ vài trăm ha và có khi lên đến cả vài ngàn thửa (vùng kín) như bạn. Tôi có theo dõi mấy cái topic của bạn và thấy tại sao bạn ko dùng Autodesk CadMap nhỉ... Trong cadmap có các công cụ phục vụ riêng cho bản đồ mà bạn nên khai thác như: Mapclean, topology, created_centroID, created_close_polyline và các hàm query....cực hữu dụng, chính xác, tốc độ cao khi file có nhiều đối tượng; mà nó lại sẵn có ngay trong cadmap và chạy tự động ? Việc còn lại là căn cứ kết quả của cadmap ta làm thêm các tiện ích phục trợ (viết bằng gì thì do bạn chọn) để bổ sung thêm cho công việc của mình mà bản thân trong cadmap nó thiếu. Ví dụ như topic hôm nọ của bạn về "điểm trống nhất trong đa giác" tôi có theo dõi và thấy anh Hoành cùng ssg mỗi người đưa ra 1 giải pháp và bạn cũng thấy nó đạt kết quả cho từng yêu cầu, chính tôi cũng chạy thử và thấy nó chạy chậm hơn đáng kể so với cadmap làm việc đó. Tuy nhiên việc giải quyết xong mấy giải thuật đó rất hay vì nó mang cả tính nghiên cứu cho phương pháp làm.

 

 

Còn về topic này của bạn việc tìm trên 1 tập hợp lớn các line ra đoạn thẳng gần nhất điểm chọn thì ngoài ý kiến của anh Hoành vầ ssg đã reply tôi có ý tưởng thế này:

Nếu bạn có thể liên kết thế bằng cách nào đó để có thể đủn số liệu ra 1 dạng database và sử dụng được các hàm SQL của một hệ quản trị cơ sở dữ liệu chắc việc thực thi tìm kết quả sẽ rất nhanh. Bạn để ý thấy các hệ quản trị cơ sở dự liệu nó chứa số liệu cực lớn thế mà dùng có mấy cái hàm query nó tìm ra kết quả vèo cái trong tích tắc !

 

ơ bổng dưng tôi cứ là người đi quảng cáo cho anh CadMap nhể !?

[tdvn 53]

õ bổng dýng tôi cứ là ngýời ði quảng cáo cho anh CadMap nhể !?

Chào bác. Em cũng biết cadmap nó có mấy cái này. Nhýng mình sử dụng nó thì mình phải phụ thuộc vào nó, nếu cái gì nó không cung cấp thì mình bí luôn. Nó rất hay, rất mạnh nhýng không phải lúc nào cũng hữu dụng. Ý em muốn xây dựng một dữ liệu riêng ðể làm theo ý mình. Em nghĩ, những phần mềm lớn có cung cấp ðủ tiện nghi cho những dự án lớn nhýng những công việc mang ðặc trýng của "việt nam" chýa chắc nó ðã chạy tốt. Vị dụ nhý việc in Hồ sõ kỹ thuật thửa ðất, lập bản vẽ phục phụ ðền bù giải phóng mặt bằng tại TPHCM ..., một số phần mềm nhý Famis trên nền Mic, cmap trên nền cadmap ... chạy chậm và nhiều lỗi. Ví dụ khi in HSKT mà muốn viết cái cụm số thửa, diện tích, loại ðất cho thửa bên cạnh, bạn phải tìm vị trí trống nhất có thể có ðể ðặt nó vào, lúc này cái lệnh tạo vùng của cadmap làm sao can thiệp ðýợc. Ngay nhý Famis của bộ TNMT tạo vùng còn lỗi quá trời, dùng thấy nản vô cùng.

Còn việc sử dụng các hệ CSDL lớn ðể quản lý là cái ðích em muốn ðạt tới và em cũng ðã thử chạy trên cad rối. Chính vì ðiều nó nên em mới tìm nguyên lý ðể lập một số hàm, lệnh chỉ có trên các CT lớn nhýng có không cung cấp, em cũng lập ðýợc rất nhiều hàm hữu ích nhýng lâu lâu cũng bí. Còn các hệ quản lý CSDL cũng không làm ðýợc cái việc nhý anh nghĩ ðâu, nếu anh không thiết kế tốt CSDL thì nó cũng không làm ðýợc gì còn cái truy vấn kiểu "tìm ðoạn thẳng gần ðiểm" em hoàn toàn không nghe thấy. Anh thấy ðấy, ngay bản thân cad, khi anh zoom all thì cái tốc ðộ bắt dính hay tạo polyline cũng giảm ðáng kể.

[elleHCSC 98]

Còn các hệ quản lý CSDL cũng không làm ðýợc cái việc nhý anh nghĩ ðâu, nếu anh không thiết kế tốt CSDL thì nó cũng không làm ðýợc gì còn cái truy vấn kiểu "tìm ðoạn thẳng gần ðiểm" em hoàn toàn không nghe thấy.

 

Đúng là mình cũng chưa được nghe thấy điều này nhưng ý mình muốn nói là có thể làm cách nào để sử dụng được kiểu truy vấn như của các hệ CSDL không để mà khai thác cái khả năng "tốc độ nhanh" khi tìm kiếmm của nó.

Phảỉ chăng mục đích câu hỏi của bạn là để tìm cách tự động tạo được các Closed_polyline trên trên một tập hợp các Line có sẵn của cad ?

[tdvn 53]

Đúng là mình cũng chưa được nghe thấy điều này nhưng ý mình muốn nói là có thể làm cách nào để sử dụng được kiểu truy vấn như của các hệ CSDL không để mà khai thác cái khả năng "tốc độ nhanh" khi tìm kiếmm của nó.

Phảỉ chăng mục đích câu hỏi của bạn là để tìm cách tự động tạo được các Closed_polyline trên trên một tập hợp các Line có sẵn của cad ?

Việc tự động tạo polyline thì trên cad cũng đã có rối. Nói chung mình muốn chủ động công việc của mình, những tính năng mạnh của một số phần mềm không phải lúc nào cũng dùng được. Giả sử mình quản lý một CSDL là tọa độ (chứ không phải là thực thể) của line hoặc của polyilne, sau đó cung cấp cho nó một điểm, làm sao cho nó trả về line hoặc polyline gần nhất. Lệnh truy vấn chỉ cho phép trả về hoành độ, tung độ của các line , pline có tọa độ gần điểm nhất, nhưng những line và pline này chưa hẳn là gần điểm nhât, có những line đi ngang qua điểm nhưng tọa độ của chúng rất xa, chỉ có khoảng cách của chúng là gần điểm mà thôi.

Cái hàm này rất quan trọng trong các lệnh tạo vùng, việc tìm ra đoạn thẳng gần điểm lâu hơn nhiều việc tạo 1 vùng. Hiện nay, công nghệ thành lập bản đồ và GIS cũng đã rất mạnh, việc tạo vùng là bài toán cơ bản. Ví dụ về một số phần mềm quản lý BĐĐC, khi anh cung cấp một điểm bất kỳ để cho nó báo về thông tin thửa đất thì những phần mềm này chạy cũng chậm lắm. Phần lớn những chức năng này chạy trên dữ liệu đã chuẩn hóa, trên bản đồ thành phẩm. Còn việc in hàng loạt hồ sơ kỹ thuật làm sao cho nó đỡ phải chỉnh sữa nhất, việc tự động tính diện tích thửa phân chiết với đcx vài dm2 và thành lập (trang trí tự động) bản vẽ trích thửa trên nhiều nền bản đồ địa chính khác nhau thì những phần mềm này khó phát triển lắm. Đó là một trong rất nhiều lý do tôi muốn lập được những hàm mà tôi cho là rất quan trọng

[elleHCSC 98]

Mình chưa hiểu lắm cách bạn lưu toạ độ của line (hoặc polyline) vào CSDL theo trật tự thế nào vì một line thì có dạng x1,y1,x2,2 còn polyline thì có dạng x1,y1,x2,y2....Xn,Yn giải thích thêm cho mình điều này và nếu dc thì hãy miêu tả bằng 1 số liệu ví dụ cụ thể.

 

 

Lệnh truy vấn chỉ cho phép trả về hoành độ, tung độ của các line , pline có tọa độ gần điểm nhất, nhưng những line và pline này chưa hẳn là gần điểm nhât, có những line đi ngang qua điểm nhưng tọa độ của chúng rất xa, chỉ có khoảng cách của chúng là gần điểm mà thôi.

 

Bạn cần tìm line gần nhất nghĩa là tìm khoảng cách từ điểm 3 đến điểm 4 (vuông góc với line) hay từ 3 đến 1 hoặc từ điểm 3 đến điểm 2 ?

 

Nếu bạn "truy vấn" trên CSDL thì chỉ tìm dc xy của các điểm "đầu mút" của Line (polyline) nhưng nếu mục đích là tìm khoảng cách từ điểm 3 đến 4 nhỏ nhất thì rõ ràng phải tính toán thêm khoảng cách từ điểm đến line.

 

Mình cũng rất quan tâm đến vấn đề này và muốn cùng nhau thảo luận với bạn

[tdvn 53]

Mình chưa hiểu lắm cách bạn lưu toạ độ của line (hoặc polyline) vào CSDL theo trật tự thế nào vì một line thì có dạng x1,y1,x2,2 còn polyline thì có dạng x1,y1,x2,y2....Xn,Yn giải thích thêm cho mình điều này và nếu dc thì hãy miêu tả bằng 1 số liệu ví dụ cụ thể.

 

Bạn cần tìm line gần nhất nghĩa là tìm khoảng cách từ điểm 3 đến điểm 4 (vuông góc với line) hay từ 3 đến 1 hoặc từ điểm 3 đến điểm 2 ?

 

Nếu bạn "truy vấn" trên CSDL thì chỉ tìm dc xy của các điểm "đầu mút" của Line (polyline) nhưng nếu mục đích là tìm khoảng cách từ điểm 3 đến 4 nhỏ nhất thì rõ ràng phải tính toán thêm khoảng cách từ điểm đến line.

 

Mình cũng rất quan tâm đến vấn đề này và muốn cùng nhau thảo luận với bạn

tất cả các line đều được xét khoảng cách từ hai đấu mút và khoảng cách vuông góc đến điểm. Khoảng cách nào ngắn hơn sẽ được chọn để trả về. Bài toán trả vể tọa độ gần điểm thì dễ, nhưng bài toán trả vể khoảng cách gần điểm thì không dễ. Nếu không có hàm chọn trước các line và pline trong của sổ kiểu ssget để hạn chế số lượng kiểm tra thì rất chậm. Do đó, cái hàm kiểu ssget (chỉ chạy trong dữ liệu) là rất cần thiết. Cũng có thể có trường hợp tìm được đoạn thắng xa hơn nếu trên đường đi từ điểm đến đoạn thắng không cắt một đoạn thắng nào khác.

Còn cách lưu tọa độ line thì có 2 cách

- 1 là lưu từng điểm, hai là lưu từng đoạn. Quan trọng cách lưu nào sẽ chạy nhanh hơn nay khi ứng dụng đã hoàn thành.

Ví dụ :

Đối với line id1

x1, y1, id1

x2, y2, id1

hoặc

x1, y1, x2, y2, id1

Đối với pline id2 có 3 điểm

x1, y1, id2

x2, y2, id2

x3, y3, id2

hoặc

x1, y1, x2, y2, id2

x2, y2, x3, y3, id2

[Nguyen Hoanh 4669]

Chủ đề thì hay, nhưng không hiểu mục đích cuối của Tdvn.

 

Nếu bạn:

- Cần người khác tối ưu thì bạn phải post chương trình và dữ liệu của bạn lên (không cần mã nguồn) để mọi người chạy thử rồi sẽ làm thử xem có tối ưu hơn bạn không? Bạn cứ nghĩ rằng số line của bạn là nhiều nhưng có thể bạn quên mất là các hàm có sẵn của ACAD được xây dựng siêu tối ưu. Chưa chắc số đối tượng mà bạn cho là nhiều đó đã gặp trở ngại khi thực hiện các thuật toán thông dụng bằng hàm của ACAD cung cấp. Trong kinh nghiệm lập trình dưới ACAD, tôi chưa bao giờ thấy vấn đề gì xảy ra nếu tốc độ thuật toán là một vòng lặp (tức là độ phức tạp thuật toán tỷ lệ với N - số đối tượng xét).

- Nếu bạn cần thuật toán tối ưu thì chẳng có thuật nào ngoài rà soát hết tất cả các line để xác định. Dùng hàm ssget chẳng qua là nhờ AutoCAD (dùng các thuật toán của nó) rà trước qua các đối tượng giúp bạn khoanh vùng đối tượng trước khi thực hiện thuật toán. Còn bản chất của các quá trình query nhanh là vì dữ liệu trước khi query đã được đánh index, trong trường hợp của bạn khó hy vọng một cách query nào đó để tiết kiệm thời gian, vì thời gian đánh index thì vẫn là tỷ lệ với N.

 

Những phân tích gợi ý của bạn chỉ làm những người muốn giúp bạn càng thêm mông lung về mục đích cuối.

[phamthanhbinh 3147]

Chào các bạn cadviet. Có lẽ mình ðến với diễn ðàn này hõi trễ nên có những cái mình cứ loay hoay mãi. Hôm nay mình mạnh dạn ðề xuất thêm một chủ ðề nữa (sau chủ ðề "tìm vị trí trống nhất trong ða giác"), cũng là chủ ðề làm mình mất ãn mất ngủ. Chủ ðề nghe rất quen thuộc nhýng cũng rất khó (ðối với mình). Ðó là chủ ðề "Tìm ðoạn thẳng gần ðiểm nhất".

Các bạn thấy ðấy, trong các phần mềm bản ðồ và cả trong cad, khi tính diện tích bạn Pick vào một ðiểm, chýõng trình sẽ tìm ðoạn thẳng gần ðiểm nhất và sau ðó sẽ tìm ðýờng bao. Hay các kiểu bắt ðiểm trong cad tôi nghĩ cũng theo cõ chế này. Theo suy nghĩ thông thýờng thì ta lập vòng lặp ði qua tất cả các ðoạn thẳng và tìm khoảng cách ngắn nhất từ ðiểm ðến ðoạn thẳng hay ðến hai ðầu ðoạn thẳng. Nhýng trong bản vẽ có vô số ðoạn thẳng (vài trãm ngàn hoặc hõn) và dài ngắn khác nhau nên thời gian lặp là rất lâu. Nếu sử dụng lệnh chọn ðối týợng theo hình vuông lớn dần có tâm là ðiểm trên ðể hạn chế số lýợng ðoạn thẳng cũng không tiện vì cad chỉ chọn các ðối týợng có trên màn hình. Hiện nay mình cũng ðang dùng tạm kiểu này, cứ mỗi lần nhý vậy phải ðýa ðiểm ðến tâm màn hình làm cho nó cứ pan liên hồi

Có thể ðây là bài toán cãn bản của ngành lập trình nhýng mình không phải là dân công nghệ thông tin chính quy nên mình cũng không biết ðã có giải thuật này hay chýa. Bạn nào có ý týởng hay thì giải giúp mình nhé.

Chào các bác tdvn, nguyenhoanh, ssg,......

Mình là lính mới tò te trong cái món lập trình này. Tuy vậy cũng mạo muội xin có tí ý kiến như sau:

Để tìm cái đường thẳng gần với một điểm cho trước nhất có thể dựa vào một cái tính chất rất trẻ con từ thời học phổ thông này hay không nhỉ? Đó là: dây cung càng dài thì khoảng cách tới tâm càng nhỏ.

Nếu được vậy ta sẽ có thể lập trình theo hướng là:

1/- dựng đường tròn bán kính đủ nhỏ, tâm là điểm đã cho.

2/- Đường tròn này sẽ cắt các đường thẳng gần nó theo các day cung,

3/- so sánh độ dài các dây cung này để tìm ra đường gần nhất.

 

Ý tưởng là vậy nhưng còn lập trình để thực hiện nó thì mình còn đang rất lúng túng, các bác thử xem nhé.

[tdvn 53]

Chủ đề thì hay, nhưng không hiểu mục đích cuối của Tdvn.

 

Nếu bạn:

- Cần người khác tối ưu thì bạn phải post chương trình và dữ liệu của bạn lên (không cần mã nguồn) để mọi người chạy thử rồi sẽ làm thử xem có tối ưu hơn bạn không? Bạn cứ nghĩ rằng số line của bạn là nhiều nhưng có thể bạn quên mất là các hàm có sẵn của ACAD được xây dựng siêu tối ưu. Chưa chắc số đối tượng mà bạn cho là nhiều đó đã gặp trở ngại khi thực hiện các thuật toán thông dụng bằng hàm của ACAD cung cấp. Trong kinh nghiệm lập trình dưới ACAD, tôi chưa bao giờ thấy vấn đề gì xảy ra nếu tốc độ thuật toán là một vòng lặp (tức là độ phức tạp thuật toán tỷ lệ với N - số đối tượng xét).

- Nếu bạn cần thuật toán tối ưu thì chẳng có thuật nào ngoài rà soát hết tất cả các line để xác định. Dùng hàm ssget chẳng qua là nhờ AutoCAD (dùng các thuật toán của nó) rà trước qua các đối tượng giúp bạn khoanh vùng đối tượng trước khi thực hiện thuật toán. Còn bản chất của các quá trình query nhanh là vì dữ liệu trước khi query đã được đánh index, trong trường hợp của bạn khó hy vọng một cách query nào đó để tiết kiệm thời gian, vì thời gian đánh index thì vẫn là tỷ lệ với N.

 

Những phân tích gợi ý của bạn chỉ làm những người muốn giúp bạn càng thêm mông lung về mục đích cuối.

Cám ơn tất cả sự nhiệt tình của các bạn.

Mục đích của mình là như vậy:

-1: Nếu trên dữ liệu line, muốn đóng vùng (trong dữ liệu tôa độ) các line khép kín thông qua điểm cung cấp (cũng trong dữ liệu)

-2: Nếu là pline, mình muốn biết điểm cung cấp thuộc pline nào (thông qua tọa độ và id của nó đã được quản lý)

và một số vấn đề khác nữa ví dụ như trả về thuộc tính của thửa đất (họ tên, địa chỉ, diện tích ...) thông qua tọa độ cung cấp, cái này thường thấy trên các hệ GIS

Vần đề thứ 2, và 3 mình chưa làm.

Vấn đề 1 mình đã thử giải quyết bằng 2 cách,

- một là theo hàm ssget của cad, chọn ra một số line nằm trong cửa sổ có tâm là điểm cung cấp, sau đó tìm line gần nhất, lấy tọa độ cung cấp cho chương trình làm hướng xuất phát tìm đường bao và tính diện tích

- hai là mình xây dựng cái hàm kiểu ssget, tìm ra một số line (trong dữ liệu) gần điểm, sau đó tìm line gần nhất rồi cũng làm như trên. Cả hai cách này đều không dùng lệnh tạo polyline của cad mà mình tự xây dựng một hàm riêng.

Khi chạy 2 cách trên trên một máy tính yếu, mình thấy rất rõ cách 2 chạy nhanh hơn, có điều, ở cách 2, cách chọn đoạn thẳng gần nhất không tốt nên đôi lúc mính pick vào thửa đát này nó lại chạy qua thửa khác.

Hiện nay mình đang dùng cách 1. Còn cách 2 đang thử dở dang vì bận việc quá mình bỏ ngang, đã hơn 1 năm rối. Để mình kiểm tra lại và làm cho nó rõ ràng rồi post lên để các bạn xem và góp ý

Cách của bạn phamthanhbinh thi khong được rồi vì vấn đề là làm sao tìm được tập hợp các line gần nhất rối mới kiểm tra cái nào gần hơn. còn nếu kiểm tra trên toàn bản vẽ thì chậm lắm

[Nguyen Hoanh 4669]

Như vậy, mục đích của bạn là tìm hướng xuất phát cho đường boundary chứ không phải là tìm điểm gần nhất. Nếu như chỉ là tìm điểm xuất phát cho boundary, bạn đâu cần tìm điểm gần nhất? mà bạn chỉ cần tìm điểm chắc chắn nằm trên boundary thôi đúng không?

[elleHCSC 98]

Cám ơn tất cả sự nhiệt tình của các bạn.

Mục đích của mình là như vậy:

-1: Nếu trên dữ liệu line, muốn đóng vùng (trong dữ liệu tôa độ) các line khép kín thông qua điểm cung cấp (cũng trong dữ liệu)

-2: Nếu là pline, mình muốn biết điểm cung cấp thuộc pline nào (thông qua tọa độ và id của nó đã được quản lý)

và một số vấn đề khác nữa ví dụ như trả về thuộc tính của thửa đất (họ tên, địa chỉ, diện tích ...) thông qua tọa độ cung cấp, cái này thường thấy trên các hệ GIS

Vần đề thứ 2, và 3 mình chưa làm.

Vấn đề 1 mình đã thử giải quyết bằng 2 cách,

- một là theo hàm ssget của cad, chọn ra một số line nằm trong cửa sổ có tâm là điểm cung cấp, sau đó tìm line gần nhất, lấy tọa độ cung cấp cho chương trình làm hướng xuất phát tìm đường bao và tính diện tích

- hai là mình xây dựng cái hàm kiểu ssget, tìm ra một số line (trong dữ liệu) gần điểm, sau đó tìm line gần nhất rồi cũng làm như trên. Cả hai cách này đều không dùng lệnh tạo polyline của cad mà mình tự xây dựng một hàm riêng.

Khi chạy 2 cách trên trên một máy tính yếu, mình thấy rất rõ cách 2 chạy nhanh hơn, có điều, ở cách 2, cách chọn đoạn thẳng gần nhất không tốt nên đôi lúc mính pick vào thửa đát này nó lại chạy qua thửa khác.

Hiện nay mình đang dùng cách 1. Còn cách 2 đang thử dở dang vì bận việc quá mình bỏ ngang, đã hơn 1 năm rối. Để mình kiểm tra lại và làm cho nó rõ ràng rồi post lên để các bạn xem và góp ý

Cách của bạn phamthanhbinh thi khong được rồi vì vấn đề là làm sao tìm được tập hợp các line gần nhất rối mới kiểm tra cái nào gần hơn. còn nếu kiểm tra trên toàn bản vẽ thì chậm lắm

 

Mình đã hiểu mục đính cuối của bạn, đó là khi pick 1 điểm (đại loại cứ hiểu là vào trong 1 thửa đất) thì cái bạn cần là từ tập hợp các line để "khoanh vùng" cái thửa đất đó chính xác? Khi đã khoanh vùng đc thửa thì cũng tự động đóng vùng được và từ đó sẽ làm được nhiều việc như tính được diện tích, lập HSKT...v.v Mình cũng loay hoay với chủ đề này khá lâu và có thể cùng thảo luận thế này.

 

Để tìm chính xác và tìm được 1 vùng thì có cách quét tòan bộ các line trên bản vẽ (vét cạn) thì chắc mới ổn

- Bạn nên lưu toàn bộ các line hoặc polyline theo dạng: x1,y1,x2,y2,id_line, tất cả cảc polyline cũng chuyển thành lưu dạng :

x1,y1,x2,y2,id_line

x2,y2,x3,y3,id_line

.... v.v.

Xn,Yn2,Xn+1,Yn+1,id_line

tại sao vậy? theo tôi nên chuyển hết về lưu trên CSDL dạng Line vì nó giữ được vectơ của line. Có thể vì bạn lưu dữ liệu cho cả polyline dạng x1,y1,x2,y2....xn,yn nên nó mới lẫn sang polyline khác, thực chất polyline cũng là 1 chuỗi các line nối liền nhau mà thôi.

Bạn cần tìm khoảng cách từ điểm đến line cả 2 trường hợp là khoảng cách từ điểm (gọi tắt là P0) đến 2 đầu mút và từ p0 vuông góc đến line? việc tìm khoảng các từ p0 đến 2 đầu mút khỏi bàn còn từ p0 vuông góc đến line thì tôi có thể góp ý thể này:

1. check xem p0 có nằm trên line không (dùng các tính của dân trắc địa): tính góc kẹp hợp thành từ p0 đến đầu mút1 (p1) và từ p0 đến đầu mút 2 (p2). Nếu góc kẹp=180 độ (pi) thì nằm trên line đó là line gần p0 nhất, nếu không (tức là ko nằm trên line) thì:

2. tính khoảng cách từ từ p0 đến line (từ góc kẹp trên). sin hay cos gì vài phát là ra ngay khoảng cách đến line.

3. Lặp lại các bước trên với tất cả các line.

theo mình để ssget nó loại bỏ bớt các line không cần thiết và làm cho tốc độ nhanh chỉ còn cách là bản đồ phải chuẩn (nghĩa là khi vẽ phải phân lớp tốt) nếu không thì chỉ còn cách filter theo LINE hoặc POLYLINE.

Bạn mà dùng lisp để viết mấy hàm tính toán khoảng cách hay góc kẹp này thì nhanh lắm, còn dùng C++ hay delphi thì hơi vất vả

 

Tôi thì giải quyết làm mấy cái tính diện tích và lập HSKT theo hướng khác, nghĩa là thửa phải được đóng vùng trước, vừa đóng vùng user có thể vừa kiểm tra được thửa (closed_polyline). Nếu bản đồ ít thửa thì công user ngồi bpoly không tốn lắm, nếu bản đồ lớn thì bắt buộc user phải phân lớp chuẩn, sau đó cadmap có sẵn tự động đóng vùng (cái này ciũng khá nhanh vì việc cài cadmap với cad phổ thông thì cài cadmap có lợi hơn). Từ đây có thể dùng để làm các công đoanj khác như tính diện tích, lập hồ sơ kỹ thuật, cũng nhanh thôi chứ ko thấy chậm như bạn nghĩ (tool của tôi chạy nhanh hơn của cmap rất nhiều 1000 HSKT chạy chuă đầy 60 giây).

[tdvn 53]

Như vậy, mục đích của bạn là tìm hướng xuất phát cho đường boundary chứ không phải là tìm điểm gần nhất. Nếu như chỉ là tìm điểm xuất phát cho boundary, bạn đâu cần tìm điểm gần nhất? mà bạn chỉ cần tìm điểm chắc chắn nằm trên boundary thôi đúng không?

À, đúng rồi. Sau khi cung cấp 1 điểm, mình sẽ tìm được hướng xuất phát (mình nghỉ hướng đó sẽ gần điểm nhất) để tạo một đường bao khép kín, nhỏ nhất bao quanh điểm đó (vấn đề là trên dữ liệu lớn các line). Có điều mình muốn là việc này được thực thi trên dữ liệu chứ không phải trên thực thể, hoặc ít nhất, mình không cho cad "thấy" cái điểm và những line bao quang nó trên màn hình

[tdvn 53]

(tool của tôi chạy nhanh hơn của cmap rất nhiều 1000 HSKT chạy chuă đầy 60 giây).

Đây là lần đầu tiên mình nghe thấy cái tool chạy HSKT nhanh kinh hoàng như vậy, bạn có quảng cáo quá không đấy, quan trọng là chạy xong rồi chỉnh sửa nhiều không, hồi mình thấy cmap chạy trên cadmap14 mỗi lần khoảng chục thửa rồi chạy tiếp. nhưng chạy xong còn phải chỉnh sửa nhiều lắm, famíc cũng không hơn

[elleHCSC 98]

Đây là lần đầu tiên mình nghe thấy cái tool chạy HSKT nhanh kinh hoàng như vậy, bạn có quảng cáo quá không đấy, quan trọng là chạy xong rồi chỉnh sửa nhiều không, hồi mình thấy cmap chạy trên cadmap14 mỗi lần khoảng chục thửa rồi chạy tiếp. nhưng chạy xong còn phải chỉnh sửa nhiều lắm, famíc cũng không hơn

Famis cũng chỉ chạy cho từng thửa, nghĩa là bạn pick vào tung centroID, cmap thì có option cho chạy cả tờ bản đồ nhưng tốc độ chậm. mình không quảng cáo mà cũng kế thừa từ famis hay cmap đển tránh các lỗi đó, tất nhiên chạy xong vẫn cần phải kiểm tra lại một chút nhưng vì cả 1000 thửa đó tôi ném vào 1 file, mỗi thửa nằm trên 1 layer nên khi in rất nhanh (làm thêm 1 cái lisp để in theo từng layer). Việc phai sửa nhiều nhất của user chỉ khi nào có lấy yếu tố thửa liền kề (tên các số thửa liền kề, tên chủ) nếu ko lấy thì kết quả đạt rất cao.

[tdvn 53]

Famis cũng chỉ chạy cho từng thửa, nghĩa là bạn pick vào tung centroID, cmap thì có option cho chạy cả tờ bản ðồ nhýng tốc ðộ chậm. mình không quảng cáo mà cũng kế thừa từ famis hay cmap ðển tránh các lỗi ðó, tất nhiên chạy xong vẫn cần phải kiểm tra lại một chút nhýng vì cả 1000 thửa ðó tôi ném vào 1 file, mỗi thửa nằm trên 1 layer nên khi in rất nhanh (làm thêm 1 cái lisp ðể in theo từng layer). Việc phai sửa nhiều nhất của user chỉ khi nào có lấy yếu tố thửa liền kề (tên các số thửa liền kề, tên chủ) nếu ko lấy thì kết quả ðạt rất cao.

Vấn ðề chính là phải trình bày các thửa liền kề và các nội dung liên quan. Ðó là lý do tôi muốn tìm vị trí trống nhất trong ða giác. Khi in HSKT, các thửa liền kề (cả giao thông và thủy hệ) ðã bị hình vuông cắt ði thành cái ða giác bất kỳ, xác ðịnh ðýợc cái ða giác này ðôi khi cũng rất khó. Nếu xác ðịnh ðýợc nó rồi thì có thể tìm vị trí trống nhất ðể ðặt cái nhóm số thửa, loại ðất, diện tích, hay tên ðýờng, tên sông vào.... Ngoài ra còn việc trình bày cự li, số hiệu ðiểm góc ranh sao cho chúng không ðè lên nhau khi thửa có khá nhiều cạnh cũng không hề ðõn giản. Nếu bạn làm tất cả những chuyện ðó mà với tốc ðộ nhý trên thì quá nhanh.

À, tôi không rõ bằng cái cách gì mà bạn có thể tung 1000 thửa vào một file nhỉ. Bạn chèn vào sau khi chúng ðã thành file (mỗi file một thửa) ? Nếu ngay trong thời ðiểm ðang xuất HSKT mà bạn có thể ném chúng vào một file thì tôi chýa nghĩ ra.

[tdvn 53]

Bài toán "Tìm ðoạn thẳng gần ðiểm nhất", sau khi suy nghĩ thêm, có thể nói rõ ý nhý vậy :

1. Lýu tọa ðộ và handle tất cả các line (tạm thời không nói ðến pline) vào CSDL. Lýu nhý thế nào cho tối ýu cũng là vấn ðề ?

2. Ngýời sử dụng cung cấp một ðiểm. Bằng cách nào ðó, trả về tọa ðộ ðýờng bao nhỏ nhất (hoặc tập hợp các line mà ðýờng bao ði qua) quanh ðiểm ðó.

 

Cách giải của mình về vấn ðề này nhý sau :

1. Lýu x1,y1,x2,y2, id vào một kiểu dữ liệu nào ðó

2. Khi ngýời dùng cung cấp ðiểm có tọa ðộ x,y. Thao tác x, y với CSDL trên, việc tìm ra những line có tọa ðộ 2 ðầu mút gần x, y là dễ dàng. Tuy nhiên, cách làm này không tìm ra ðýợc những line có khoảng cách gần ðiểm nhýng tọa ðộ 2 ðầu mút xa ðiểm; từ ðó, nếu rõi vào trýờng hợp này, ta không tìm ðýợc ðýờng bao ðúng vì ðiểm ðã nằm ngoài ðýờng bao.

Nếu sử dụng hàm ssget của cad, không xảy ra sai sót này nhýng ssget chạy trên thực thể nhìn thấy chứ không chạy trên dữ liệu

Hình minh họa :

http://www.cadviet.com/upfiles/TAM.jpg

Ðiểm do ngýời dùng nhập là O.

Nếu dùng (ssget "c" ) của cad với cửa sổ nào ðó, ta ðýợc tập hợp chọn là những ðoạn thẳng AB, CD, CE hoặc có thể thấy ngay AB và ðýờng bao tìm ðýợc là ABGF (ðúng)

Còn cách làm của tôi chỉ ðýợc CD, CE. và ðýờng bao tìm ðýợc là ABECD không chứa ðiểm O (sai). Làm sao thấy ðýợc trong ðó còn có AB một cách ðõn giản nhất, nhanh nhất ðể tím ðýờng bao chính xác

Tất nhiên, chúng ta phải xét là dữ liệu line rất lớn và các ðoạn thẳng dài ngắn khác nhau

[tdvn 53]

Sau khi suy nghĩ thêm và theo gợi ý của bác Nguyen Hoanh, tôi thấy sáng thêm và goí gọn chủ ðề này bao gồm 3 býớc chính :

1- Quản lý dữ liệu line theo cách thức nào ðó.

2- Trên dữ liệu ðó, tìm tập hợp (càng ít càng tốt) các ðoạn thẳng gần ðiểm (ðiểm do ngýời dùng cung cẩp)

3- Từ ðó tìm ra ðoạn thẳng xuất phát cho ðýờng boundary

Mong ðýợc các bạn tham gia hỗ trợ những ý týởng hay.

[Nguyen Hoanh 4669]

Sau khi suy nghĩ thêm và theo gợi ý của bác Nguyen Hoanh, tôi thấy sáng thêm và goí gọn chủ ðề này bao gồm 3 býớc chính :

1- Quản lý dữ liệu line theo cách thức nào ðó.

2- Trên dữ liệu ðó, tìm tập hợp (càng ít càng tốt) các ðoạn thẳng gần ðiểm (ðiểm do ngýời dùng cung cẩp)

3- Từ ðó tìm ra ðoạn thẳng xuất phát cho ðýờng boundary

Mong ðýợc các bạn tham gia hỗ trợ những ý týởng hay.

Tôi không rõ khó khăn thực sự của bạn nằm ở đâu?

 

Thứ nhất, nếu tìm đối tượng line nằm gần điểm đã cho nhất, chưa chắc line đó đã nằm trên boudary. VD:

 

Thứ hai, nếu chắc chắn các đối tượng đã được vẽ thành các miền kín, thì không cần phải tìm điểm gần nhất mà vẫn có thể tìm được line nằm trên boudary bằng thuật toán khác.

 

Bạn có thể upload 1 file dwg ví dụ lên diễn đàn và giải thích rõ hơn về khó khăn của bạn?

[tdvn 53]

Tôi không rõ khó khăn thực sự của bạn nằm ở đâu?

 

Thứ nhất, nếu tìm đối tượng line nằm gần điểm đã cho nhất, chưa chắc line đó đã nằm trên boudary. VD:

 

Thứ hai, nếu chắc chắn các đối tượng đã được vẽ thành các miền kín, thì không cần phải tìm điểm gần nhất mà vẫn có thể tìm được line nằm trên boudary bằng thuật toán khác.

 

Bạn có thể upload 1 file dwg ví dụ lên diễn đàn và giải thích rõ hơn về khó khăn của bạn?

Tôi kèm một cái file mẫu cho bạn. Tôi chọn file vừa đủ lớn cho thấy sự phức tạp của nó và cũng đã xóa bớt các nội dung khác (đầy đủ khoảng 19M)

http://www.cadviet.com/upfiles/mau_1.dwg

Tôi nói sơ qua về cái file này cho bạn rõ :

Đây là một file bản đồ địa chính. Tất cả ranh giới thửa đất nằm trong các layer có phần đầu cố định là "Zranh", phần tiếp sau để diễn tra nét đặc trưng của nó. Ví dụ : "Zranhrach" : ranh giáp rạch. "Zranhduong" : ranh giáp đường ...

Ở trong một thửa (là khái niệm địa chính chỉ một vùng khép kín, một số phần mềm cho hẳn nó là một cái polyline), tôi có một dấu "*" (nó đơn giản là text) để định vị, để xác định đường bao khi cần và cũng để tôi gởi cái thuộc tính như : Họ tên, địa chỉ ... vào trong đó, tất cả có khoảng 6000 thửa. Và bạn thấy đấy, trên bản vẽ của tôi không có một cái polyline nào.

Khi cần tính diện tích, tôi pick vào trong một thửa, chương trình (do tôi viết) căn cứ vào tọa độ vừa pick, tìm đoạn thẳng gần nhất, xác định vị trí của điểm và 2 đầu mút và tìm ra đường đi qua các line khép kín theo chiều ngược kim đồng hồ, vẽ cho tôi thấy hình ảnh của nó và trả về diện tích. Khi muốn tính diện tích tự động, tôi chọn những cái dấu "*", lấy tọa độ của nó cung cấp cho chương trình như trên. Nếu chương trình đang chạy mà gặp cái ngõ cụt, như minh hỏa của bạn, chương trình sẽ lùi lại tìm đường khác để đi, nếu đi không được nó báo "Không khép" và dừng lại. Trong khi chạy, chương trình không tạo ra một cái polyline nào, nó chỉ tìm các tọa độ liên tiếp qua các line khép kín mà thôi. Việc tìm đường bao và tính diện tích của tôi không sử dụng tiện ích boudary hay cadmap vì tối còn có những ý định khác nữa.

 

Trong chương trình của tôi có hàm tìm đoạn thẳng gần nhất để làm hướng xuât phát, trong đó có dùng hàm (ssget "c" ....)

Cái khó khăn nằm ở chỗ này. bạn biết đất, hàm ssget chạy trên thục thể nhìn thấy. nếu ở độ zoom không phù hợp, không có đối tượng cần tìm trên màn hình, hàm ssget trả về nil và dẫn đến chương trình chạy sai. Nếu zoom all, khi công việc của tôi thay đổi vị trí và tầm nhìn liên tục, việc tái tạo màn hình với dữ liệu lơn như vậy sẽ mất rất nhiêu thời gian.

Mặc khác, tôi muốn việc tìm hướng xuất phát diễn ra trên dữ liệu mà việc này đòi hỏi phải có hàm tìm ra các đoạn thẳng (thông qua tọa độ của nó đã được quản lý) gần điểm trước giống như hàm ssget.