Opened 15 years ago

Closed 14 years ago

Last modified 14 years ago

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

hgp-contour-direction-patch.patch (6.8 KB ) - added by GregersP 15 years ago.

Download all attachments as: .zip

Change History (7)

by GregersP, 15 years ago

comment:1 by asgerpetersen, 15 years ago

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?

in reply to:  1 comment:2 by GregersP, 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 warmerdam, 15 years ago

Cc: warmerdam added
Keywords: contour added
Milestone: 1.7.0
Owner: changed from warmerdam to chaitanya

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:4 by chaitanya, 14 years ago

Status: newassigned

Applied the patch in r18418 in trunk.

comment:5 by chaitanya, 14 years ago

Resolution: fixed
Status: assignedclosed

Added a test and documentation in r18420 in trunk.

comment:6 by Even Rouault, 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)"

Note: See TracTickets for help on using tickets.