Ticket #3129 (closed enhancement: fixed)

Opened 2 years ago

Last modified 2 years ago

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

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

Change History

Changed 2 years ago by GregersP

follow-up: ↓ 2   Changed 2 years ago by 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?

in reply to: ↑ 1   Changed 2 years ago by GregersP

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

  Changed 2 years ago by warmerdam

  • cc warmerdam added
  • keywords contour added
  • owner changed from warmerdam to chaitanya
  • milestone set to 1.7.0

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.

  Changed 2 years ago by chaitanya

  • status changed from new to assigned

Applied the patch in r18418 in trunk.

  Changed 2 years ago by chaitanya

  • status changed from assigned to closed
  • resolution set to fixed

Added a test and documentation in r18420 in trunk.

  Changed 2 years ago by rouault

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.