Why do we have the "Area too small to split at ..." message
Hi, I wonder if this message is really useful. I see this typically for large shapes, the last example from Thorsten has two identical large shapes (the island Rügen) http://www.openstreetmap.org/browse/relation/54400 The message is printed because area.getEstimatedSizes() returns values that are higher than some limits. The problem: area.getEstimatedSizes() ignores the filters which are used to reduce the number of points, so the error message may be printed without any reason. I think it would be better to do something like this: oldPos = buffer.getPosition() add the shape bytes = buffer.getPosition() - oldPos; if (bytes > LIMIT) { print error message } This would also allow to report the name of the shape that is probably corrupted. Of course, the same can be done for ways or node. What do you think? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Why-do-we-have-the-Area-too-small-to-split-at... Sent from the Mkgmap Development mailing list archive at Nabble.com.
In any case this shouldn't be a warning message IMHO, but an info message. That way real warnings could be logged without junk (junk from a position of simply rendering the map, without wanting to solve problems on the input - so if you not only create one map, but plenty to offer for download)... but the proposal is IMHO much better - but please as info and not as warning. (Warnings should be buffer overruns, tiles failing to compile due to various reasons, out of memory, and such grave errors). On 15.01.2013 12:12, GerdP wrote:
Hi,
I wonder if this message is really useful. I see this typically for large shapes, the last example from Thorsten has two identical large shapes (the island Rügen) http://www.openstreetmap.org/browse/relation/54400
The message is printed because area.getEstimatedSizes() returns values that are higher than some limits. The problem: area.getEstimatedSizes() ignores the filters which are used to reduce the number of points, so the error message may be printed without any reason.
I think it would be better to do something like this: oldPos = buffer.getPosition() add the shape bytes = buffer.getPosition() - oldPos; if (bytes > LIMIT) { print error message }
This would also allow to report the name of the shape that is probably corrupted. Of course, the same can be done for ways or node.
What do you think?
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/Why-do-we-have-the-Area-too-small-to-split-at... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org
Felix Hartmann-2 wrote
but the proposal is IMHO much better - but please as info and not as warning. (Warnings should be buffer overruns, tiles failing to compile due to various reasons, out of memory, and such grave errors).
I worked for 15 years on IBM mainframe systems (z/OS) coding batch programs. On z/OS, it is common to use return codes 0,4,8,12, and 16. My company use them like this 0 means everything ok 4 means their are warning messages, but the result is probably correct 8 means their are errors in the input data, and maybe output data is incomplete or wrong. 12 means a configuration problem (e.g. missing parameters) or missing licence key 16 means severe error, program can't continue (something like Out of memory) Some operators asked us to implement parameters to set rc=0 even if there were errors, because rc=0 means they did a good work ;-) I think an error should produce an error message, but the message should be clear enough so that the user can decide what to do. Ciao, Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Why-do-we-have-the-Area-too-small-to-split-at... Sent from the Mkgmap Development mailing list archive at Nabble.com.
On Tue, Jan 15, GerdP wrote:
I think an error should produce an error message, but the message should be clear enough so that the user can decide what to do.
Correct. And for errors I want to ignore I use grep/perl to remove them from the log file, so that I have only the errors I'm interested in at the end. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
On Tue, Jan 15, GerdP wrote:
I think it would be better to do something like this: oldPos = buffer.getPosition() add the shape bytes = buffer.getPosition() - oldPos; if (bytes > LIMIT) { print error message }
This would also allow to report the name of the shape that is probably corrupted. Of course, the same can be done for ways or node.
What do you think?
I like it and I think this would be a huge improvement. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Hi,
I wonder if this message is really useful. I see this typically for large shapes, the last example from Thorsten has two identical large shapes (the island Rügen) http://www.openstreetmap.org/browse/relation/54400
The message is printed because area.getEstimatedSizes() returns values that are higher than some limits. The problem: area.getEstimatedSizes() ignores the filters which are used to reduce the number of points, so the error message may be printed without any reason.
I think it would be better to do something like this: oldPos = buffer.getPosition() add the shape bytes = buffer.getPosition() - oldPos; if (bytes > LIMIT) { print error message }
This would also allow to report the name of the shape that is probably corrupted. Of course, the same can be done for ways or node.
What do you think?
Gerd
Hi Gerd, of course you can move the error message but I think your proposal does not solve the problem. As far as I understand the current processing is: 1. MapBuilder processes all Map objects (cities, roads, POIs etc.). 2. Then these objects must be separated into subdivisions. Subdivisions have some limits so MapSplitter (who does this job) checks these limits while adding objects to a list (MapArea) that is converted to a subdivision later. 3. The objects from the MapArea are filtered when creating the subdivions. Now you are right. The filters probably will reduce the number of points etc. and therefore there will be some more space until the limits of a subdivion are reached. The error message appears at step 2 where the MapSplitter tries to collect as many objects as possible. At first all objects are taken and as long as a limit is exceeded the whole area is split into two areas. A polygon is put into the area where its center is located. If the larger side of the area is <= 10 units the area is no longer split and the error message is printed. This happens if you have two identical large polygons. No matter how often MapSplitter splits the areas both polygons will always have the same center point and are put into the same area. Together they exceed the limits of a single subdivision and therefore the MapSplitter tries to split the area again. If you want to remove the reason of the error message you would have to change the way how subdivisions are created. WanMil
WanMil wrote
of course you can move the error message but I think your proposal does not solve the problem.
As far as I understand the current processing is: 1. MapBuilder processes all Map objects (cities, roads, POIs etc.). 2. Then these objects must be separated into subdivisions. Subdivisions have some limits so MapSplitter (who does this job) checks these limits while adding objects to a list (MapArea) that is converted to a subdivision later. 3. The objects from the MapArea are filtered when creating the subdivions. Now you are right. The filters probably will reduce the number of points etc. and therefore there will be some more space until the limits of a subdivion are reached.
The error message appears at step 2 where the MapSplitter tries to collect as many objects as possible. At first all objects are taken and as long as a limit is exceeded the whole area is split into two areas. A polygon is put into the area where its center is located. If the larger side of the area is <= 10 units the area is no longer split and the error message is printed. This happens if you have two identical large polygons. No matter how often MapSplitter splits the areas both polygons will always have the same center point and are put into the same area. Together they exceed the limits of a single subdivision and therefore the MapSplitter tries to split the area again.
If you want to remove the reason of the error message you would have to change the way how subdivisions are created.
Hi WanMil, Yes, that is exactly the problem. What I want to change is that mkgmap prints the error message even when no problem occurs. You can have two situations: 1) two or more large identical polygons with many points cause the error message, but the points are saved with less bytes than estimated. In this case there is no problem 2) two or more large identical polygons with many points cause the same error message AND the points are saved with so many bytes that the limit is reached. This is an error and must be avoided. If the error hapens, I think the program will throw new IllegalStateException("Polyline offset too large: " + off); The number of bytes needed to save a polygon is variable, and afaik the current estimation is a bit too pessimistic. So, we can change two parts: 1) Remove the error message "area too small to split ..." 2) Create one area for each of the large polygons. I don't know if it would cause problems when two areas are located at the same position. If yes, we can more them a little bit. I will trace that down tomorrow. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Why-do-we-have-the-Area-too-small-to-split-at... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi, WanMil wrote
If you want to remove the reason of the error message you would have to change the way how subdivisions are created.
Attached is a patch that tries to implement a better algo. It checks for the special case were two or more (almost) identical large ways or shapes should be placed into the same area. MapArea_v1.patch <http://gis.19327.n5.nabble.com/file/n5745299/MapArea_v1.patch> Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Why-do-we-have-the-Area-too-small-to-split-at... Sent from the Mkgmap Development mailing list archive at Nabble.com.
participants (4)
-
Felix Hartmann -
GerdP -
Thorsten Kukuk -
WanMil