search

WikiWatershed / rapid-watershed-delineation

Rapid Watershed Delineation Code for MMW2
Apache License 2.0
12 stars 6 forks source link

Update simplify check for new NHD units #57

Closed mmcfarland closed 7 years ago

mmcfarland commented 7 years ago

The latest NHD based RWD code generates area output with a different unit than the previous code. This results in under-simplified geometry being returned to the client.

Previous level of simplification: screenshot from 2017-01-20 16 41 22

Current level of simplification: screenshot from 2017-01-20 16 40 54

Clearly, the less simplified version looks better, but is also quite large for a web payload.

dtarb commented 7 years ago

I like the less simplified current one too.

I am puzzled by your comment about units on area being changed. Are you referring to the changes with my current pull request https://github.com/WikiWatershed/rapid-watershed-delineation/pull/54/files, or earlier changes. The current pull request has changed the way area is calculated to use shape geometry, rather than contributing area grid, but should be reporting the area in square km in both cases. Shape geometry is better as it works for large watersheds, while the grid approach returned no data when the area crossed processing unit boundaries.

How does the area attribute and its units affect shape rendering?

Is there an option for rendering to use a zoom level dependent payload (pyramid idea) so that for zoomed out the coarse resolution data is rendered, but for zoomed in the finer data (even up to full resolution not generalized) data is rendered, but just for the area of display. This does seem to be a common approach in GIS and other web mapping systems, but I do not know what would be involved for wiki-watershed.

kdeloach commented 7 years ago

I may have misinterpreted your comment from #44. I thought the area units of measurement changed from m^2 to km^2. Apologies for the confusion.

To answer your question about how area affects shape rendering, we use area to determine how much to simplify shapes when converting them to GeoJSON. See https://github.com/WikiWatershed/rapid-watershed-delineation/blob/develop/src/api/main.py#L186.

In any case, the purpose of this task is to tweak the simplify parameter that is passed to ogr2ogr to find a good balance between performance (the amount of time it takes to convert New_Point_Watershed.shp to GeoJSON) and payload size (to minimize network bandwidth consumption and memory footprint).

Implementing zoom level dependent rendering for this feature is a great idea, but would require a non-trivial amount of effort.

dtarb commented 7 years ago

No worries. I was unclear on how far back you were looking. Pre the Nov 2016 #44 PR area may well have been in different units or even wrong. I remember there were quite a number of problems (on our end) related to the right area file being used, and weighted area calculations, that I fixed in the preprocessing of the data that accompanied that PR.

One thing that may be happening is that pre #54 many of the area field attribute values will be returned as -999 (indicating no data). This will have been the case for all large watersheds as they span NHDPlus grid processing units. With #54 I now compute area from shape geometry, so we have a value for all watersheds. The setting of tolerance would have used the smallest tolerance for -999, and now it will go to the biggest tolerance.

The result is that for large watersheds there is big simplification. This is OK for visualization at the scale of the whole watershed, but when you zoom in close along an edge you'll get the effect above.

I can appreciate that zoom level dependent rendering may be non trivial to write code for. But it does seem to be a common practice in other web mapping systems (we are not the first to face this problem) so I wonder if there is a library out there that just does this that you could use.