problem with splitter and bounding polygon
Hi, I'm trying to compile a map of USA using North America extract form Geofabrik. I use splitter r427 with bounding polygon, something like that: splitter --polygon-file=usa.poly ... north-america-latest.osm.pbf The result is that I get errors in mkgmap: SEVERE (MapFailedException): pbf\29729241.osm.pbf: (thrown in BufferedImgFileWriter.ensureSize()) There is not enough room in a single garmin map for all the input data. The .osm file should be split into smaller pieces first. This error appears for some tiles at the map border. My guess is, that splitter uses only nodes inside bounding poly to compute tiles sizes. When a rectangular tile is placed on a polygon border, estimated node number could be significantly smaller than the full number actually saved in this tile. This could lead to problems as above. I don't have any suggestions for a solution, so I'm going to try to go around it using a simplified poly. I hope, that maybe someone could get an idea how to correct it. -- Best regards, Andrzej
El 01/03/16 a las 22:23, Andrzej Popowski escribió:
Hi,
I'm trying to compile a map of USA using North America extract form Geofabrik. I use splitter r427 with bounding polygon, something like that:
splitter --polygon-file=usa.poly ... north-america-latest.osm.pbf
The result is that I get errors in mkgmap: SEVERE (MapFailedException): pbf\29729241.osm.pbf: (thrown in BufferedImgFileWriter.ensureSize()) There is not enough room in a single garmin map for all the input data. The .osm file should be split into smaller pieces first.
This error appears for some tiles at the map border.
My guess is, that splitter uses only nodes inside bounding poly to compute tiles sizes. When a rectangular tile is placed on a polygon border, estimated node number could be significantly smaller than the full number actually saved in this tile. This could lead to problems as above.
I don't have any suggestions for a solution, so I'm going to try to go around it using a simplified poly. I hope, that maybe someone could get an idea how to correct it.
Did you try reducing --max-nodes value? -- Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx, .ppt, .pptx, .mdb, mdbx Instale LibreOffice desde http://es.libreoffice.org/descarga/ LibreOffice es libre: se puede copiar, modificar y redistribuir libremente. Gratis y totalmente legal. LibreOffice está en continuo desarrollo y no tendrá que pagar por las nuevas versiones.
Hi Andrzej, I'll try to reproduce the problem. Please provide details regarding the splitter options, the poly file, and the densities-out.txt written by splitter. Gerd popej wrote
Hi,
I'm trying to compile a map of USA using North America extract form Geofabrik. I use splitter r427 with bounding polygon, something like that:
splitter --polygon-file=usa.poly ... north-america-latest.osm.pbf
The result is that I get errors in mkgmap: SEVERE (MapFailedException): pbf\29729241.osm.pbf: (thrown in BufferedImgFileWriter.ensureSize()) There is not enough room in a single garmin map for all the input data. The .osm file should be split into smaller pieces first.
This error appears for some tiles at the map border.
My guess is, that splitter uses only nodes inside bounding poly to compute tiles sizes. When a rectangular tile is placed on a polygon border, estimated node number could be significantly smaller than the full number actually saved in this tile. This could lead to problems as above.
I don't have any suggestions for a solution, so I'm going to try to go around it using a simplified poly. I hope, that maybe someone could get an idea how to correct it.
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/problem-with-splitter-and-bounding-polygon-tp... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, thanks for your interest. That was split for 7GB custom pbf, densities-out.txt was over 1GB. I will try to prepare some small subset for test. -- Best regards, Andrzej
Hi Andrzej, interesting, seems you are using a very high resolution value, else the densities-out.txt should be much smaller. With resolution 13 the latest planet file produced a file with ~ 61MB (zipped ~18MB) Maybe this is part of the problem... Gerd ________________________________________ Von: mkgmap-dev-bounces@lists.mkgmap.org.uk <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Mittwoch, 2. März 2016 08:17 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] problem with splitter and bounding polygon Hi Gerd, thanks for your interest. That was split for 7GB custom pbf, densities-out.txt was over 1GB. I will try to prepare some small subset for test. -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, I can't repeat the problem on smaller extracts. The problem is not so important, I would leave it for now, unless it reappear on easier to track dataset. -- Best regards, Andrzej
Hi Andrzej, okay, I understand. If you can reproducde it with the large file I'd still like to check that. Gerd ________________________________________ Von: mkgmap-dev-bounces@lists.mkgmap.org.uk <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Donnerstag, 3. März 2016 19:56 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] problem with splitter and bounding polygon Hi Gerd, I can't repeat the problem on smaller extracts. The problem is not so important, I would leave it for now, unless it reappear on easier to track dataset. -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, I observe the same problem using standard extract of North America http://download.geofabrik.de/north-america-latest.osm.pbf I have packed my batches and splitter output (densities, areas) into an archive: http://files.mkgmap.org.uk/download/292/split-poly2.7z I have used splitter r428 and mkgmap 3669. I hope you can repeat it with current extract, it shouldn't be much different. I got some tiles with size like 30-60MB, 2 of them didn't compile with mkgmap. Average size of tiles was about 12MB. -- Best regards, Andrzej
Hi Andrzej, I think I understand now what the problem is, and I also think that the high resolution is making it worse. The current algo in fact ignores node counts outside the polygon, the higher the resolution the smaller the grid areas and the more data outside the polygon is ignored. I don't yet have a solution, I just know that the current approach is not okay. Gerd ________________________________________ Von: mkgmap-dev-bounces@lists.mkgmap.org.uk <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Samstag, 5. März 2016 20:23 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] problem with splitter and bounding polygon Hi Gerd, I observe the same problem using standard extract of North America http://download.geofabrik.de/north-america-latest.osm.pbf I have packed my batches and splitter output (densities, areas) into an archive: http://files.mkgmap.org.uk/download/292/split-poly2.7z I have used splitter r428 and mkgmap 3669. I hope you can repeat it with current extract, it shouldn't be much different. I got some tiles with size like 30-60MB, 2 of them didn't compile with mkgmap. Average size of tiles was about 12MB. -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd,
I don't yet have a solution, I just know that the current approach is not okay.
No easy solution. I think maybe the best would be to trim border tiles according to bounding polygon. This could be suitable for irregular tiles too. Other idea could be to estimate full content of a tile on border, adding a number of nodes proportional to area outside bounding polygon. This won't be precise but I guess quite easy to implement. In my case simplification of bounding polygon was sufficient to get usable split. -- Best regards, Andrzej
Hi Andrzej, sure, if you change the poly you can avoid the situation. The problem appears most likely when a highly populated area is close to, but outside of the poly and a lowly populated area inside and the polygon line is a long diagonal line at this place. I'll see if I can improve the algo. I think as long as mkgmap doesn't support poly files we have to solve the problem in splitter. On the other hand, a simple filter in mkgmap should also be possible. We already have UnusedElementsRemoverHook.java which magically detects elements in the input file which will not appear in the output file. If we change this filter to check against a poly instead of a bbox it might be good enough. I only hesitate to implement that because one might expect that this woud also allow splitting maps at country borders, which requires much more work when routing across these borders should work. Gerd ________________________________________ Von: mkgmap-dev-bounces@lists.mkgmap.org.uk <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Sonntag, 6. März 2016 02:00 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] problem with splitter and bounding polygon Hi Gerd,
I don't yet have a solution, I just know that the current approach is not okay.
No easy solution. I think maybe the best would be to trim border tiles according to bounding polygon. This could be suitable for irregular tiles too. Other idea could be to estimate full content of a tile on border, adding a number of nodes proportional to area outside bounding polygon. This won't be precise but I guess quite easy to implement. In my case simplification of bounding polygon was sufficient to get usable split. -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd,
We already have UnusedElementsRemoverHook.java which magically detects elements in the input file which will not appear in the output file. If we change this filter to check against a poly instead of a bbox it might be good enough.
I have already tested something like that, I have extracted USA using osmosis and bounding poly. I don't like results, mostly because filtering is not precise. For example I can get a full lake area on a map but all object on an island are missing, because they are entirely outside poly, while lake is partially inside. Or I can get contours, where missing middle part is replaced by a straight line. If you are thinking about filtering in mkgmap or splitter, then I would prefer it as a precise cut and trim with bounding poly. -- Best regards, Andrzej
Hi Andrzej, okay, good points. That would probably also happen with a simple input filter in mkgmap. I'll see if I can improve splitter, I think it should be possible. Gerd ________________________________________ Von: mkgmap-dev-bounces@lists.mkgmap.org.uk <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Sonntag, 6. März 2016 15:49 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] problem with splitter and bounding polygon Hi Gerd,
We already have UnusedElementsRemoverHook.java which magically detects elements in the input file which will not appear in the output file. If we change this filter to check against a poly instead of a bbox it might be good enough.
I have already tested something like that, I have extracted USA using osmosis and bounding poly. I don't like results, mostly because filtering is not precise. For example I can get a full lake area on a map but all object on an island are missing, because they are entirely outside poly, while lake is partially inside. Or I can get contours, where missing middle part is replaced by a straight line. If you are thinking about filtering in mkgmap or splitter, then I would prefer it as a precise cut and trim with bounding poly. -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (4)
-
Andrzej Popowski -
Carlos Dávila -
Gerd Petermann -
Gerd Petermann