Andre Hinrichs <andre.hinrichs <at> gmx.de> writes: > I just saw, that the patch already went into the HEAD version. I was surprised too.
> The current version stresses the XAPI servers unnecessarily since the > XAPI is ALWAYS asked for each tile even if there is no multipolygon in > the data. I am working on this issue now quite a while and i took different approaches to close the multipolygons. Some, like "just" guess how to close, didn't work right in all situations. So i came to the conclusion that the easiest way of closing multipolygons is to fetch "all" of them in the tile's bbox completely. I'm also concerned about XAPI servers stability and ability to handle the additional load. But then i tought, the patch fixes the problem, no one else showed a solution right now and even if it tears XAPI servers down - maybe, someone sponsors a (t...@h exclusive) XAPI server to handle the load or improves multipolygon closing further without threatening XAPI servers stability. > I would highly recommend to FIRST load normal data from TRAPI and only > do necessary downloads from XAPI (multipolygon is in the data but > incomplete). At the time of writing the patch i disliked the idea to do parsing stuff at the stage where Tileset::downloadData() is running. I had in mind to write something simple, just working. But if my time permits and it's common sense that parsing at this stage is okay, i'll give your approach a try. A way to go could then be: - parse data.osm - get all relation ids with type=multipolygon - per id * fetch each relation member's data from TRAPI * close the multipolygon * cut the multipolygon along a slightly bigger tile based bbox * use multipolygon bbox intersections to close the multipolygon again - merge with data.osm earlier Andre Hinrichs <andre.hinrichs <at> gmx.de> writes: > [..] it took 603 seconds instead of 7 seconds. Then the resulting file size > was much bigger (41 MB instead of 7MB) and thus the client took much longer > to render the tile (1531 instead of 623 seconds) > [...] > And the resulting data.osm file is not loadable in JOSM [...] If the outlined approach works, the resulting file wouldn't be much bigger compared to the past, rendering times should drop back to normal and data.osm should be loadable in JOSM again. Cheers, Micha (Irrfahrt) _______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/listinfo/tilesathome
