#3129 closed enhancement (fixed)
Contour orientation
Reported by: | GregersP | Owned by: | chaitanya |
---|---|---|---|
Priority: | normal | Milestone: | 1.7.0 |
Component: | Algorithms | Version: | unspecified |
Severity: | normal | Keywords: | contour |
Cc: | warmerdam |
Description
Hi,
When building and using contours I find it nice to have a knowledge of the uphill and downhill directions, eg. when placing labels one can place them facing up-hill, or simply deciding the up-hill direction when looking at a contour direction locally.
Therefore I have made a little patch to my local version of contours.cpp, which I attach to this ticket. My solution beares evidence of the fact that I do most of my programming in other languages than C++, though - as far as I have been able to test - it should be correct.
The idea behind the patch is simple: register if it is the left or the right side, which is the high side, and use this information to make the right side the "high side" (meaning a clockwise contour around a top) when ejecting the contours.
As stated earlier I have not been able to produce errors in my tests of the code, though my patch has the assumption that a saddle would not be connected "left - top" + "bottom - right". It is stated in the comment explaining the algorithm that this might happen, though when reading through the code, I was not able to actually pinpoint the location of this type of connection.
Attachments (1)
Change History (7)
by , 15 years ago
Attachment: | hgp-contour-direction-patch.patch added |
---|
follow-up: 2 comment:1 by , 15 years ago
comment:2 by , 15 years ago
Replying to asgerpetersen:
I have also been wondering why the contours are not oriented consistently. For our use it would be a huge improvement, if they were.
Your patch looks fairly simple. Have you done any speed and memory comparisons to the original algorithm?
Hi Asger,
Nice to see you peeking here also :-)
After we had discussed the problem I made the patch, and did some comparisons to the gdal_contours present in FW Tools 2.4.3. There is no speed difference between the two solutions on my installation (actually mine was faster, but this must have been due to the fact that I do not compile a lot of the drivers etc), and only a marginally higher memory consumption of 2-5 MBs (out of 250-300MBs when running a large 10x10 km grid in a resolution of approx 2x2 meters).
comment:3 by , 15 years ago
Cc: | added |
---|---|
Keywords: | contour added |
Milestone: | → 1.7.0 |
Owner: | changed from | to
Chaitanya,
Please integrate this into trunk as time permits, and make sure the test_gdal_contour.py script is extended to do some verification of orientation.
Finally, please add some discussion on orientation into the function documentation.
comment:5 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Added a test and documentation in r18420 in trunk.
comment:6 by , 14 years ago
Chaintanya, I just did a mostly cosmetic change in r18421 : "Simplify PrepareEjection(): no need for temporary array to reverse an array (#3129)"
I have also been wondering why the contours are not oriented consistently. For our use it would be a huge improvement, if they were.
Your patch looks fairly simple. Have you done any speed and memory comparisons to the original algorithm?