Possible solution for deformed polygons
Hi all, at the end of 2012 we discussed "Polygons deformed", see http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2012q4/016010.html As already mentioned the rounding to map units can cause extreme errors in angles for points which are very close together. This is often the case in buildings, and also the angles in buildings are often right angles (90°), so errors are very obvious. I think I have a possible improvement for it: 1) merge polygons with equal types etc. like in merge-lines algo, so that e.g. buildings that share walls are combined to one polygon (without creating holes). See e.g. http://www.openstreetmap.org/browse/way/118911628 Merging allows to merge many building polygons to one, this makes it less likely that two points are close. 2) Detect and remove wrong angles with an algo similar to that used in r2829 to remove wrong angles in roads. I see two advantages: a) img files which are a bit closer to OSM data b) smaller img files (because of the merging) I see one small possible problem: The size filter might not remove merged polygons. Do you see other problems? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Possible-solution-for-deformed-polygons-tp578... Sent from the Mkgmap Development mailing list archive at Nabble.com.
...very interesting! I'll stay tuned... Thanks! --enrico -- View this message in context: http://gis.19327.n5.nabble.com/Possible-solution-for-deformed-polygons-tp578... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd,
1) merge polygons with equal types etc. like in merge-lines algo, so that e.g. buildings that share walls are combined to one polygon > (without creating holes).
I would expect that many buildings have address tag which would make merging not advisable. How merging would cooperate with option add-pois-to-areas? -- Best regards, Andrzej
Hi Andrzej, for address search the data is saved with the roads, not with the polygons and poi are separate points, so I don't see a problem here. I did not yet start coding, as I still try to find a better algo for the bad angles in roads. Gerd popej wrote
Hi Gerd,
1) merge polygons with equal types etc. like in merge-lines algo, so that e.g. buildings that share walls are combined to one polygon > (without creating holes).
I would expect that many buildings have address tag which would make merging not advisable.
How merging would cooperate with option add-pois-to-areas?
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Possible-solution-for-deformed-polygons-tp578... Sent from the Mkgmap Development mailing list archive at Nabble.com.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Gerd, if this merging is done after style-processing, then it should be a great improvement without complications. Otherwise only polygons should be merged if all tags are equal. Henning Am 23.11.2013 16:25, schrieb GerdP:
Hi Andrzej,
for address search the data is saved with the roads, not with the polygons and poi are separate points, so I don't see a problem here. I did not yet start coding, as I still try to find a better algo for the bad angles in roads.
Gerd
popej wrote
Hi Gerd,
1) merge polygons with equal types etc. like in merge-lines algo, so that e.g. buildings that share walls are combined to one polygon > (without creating holes).
I would expect that many buildings have address tag which would make merging not advisable.
How merging would cooperate with option add-pois-to-areas?
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Possible-solution-for-deformed-polygons-tp578...
Sent from the Mkgmap Development mailing list archive at Nabble.com.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQEcBAEBAgAGBQJSkNa2AAoJEPFgsWC7jOeTG+EIALR1DG4mMeJ1996r8ZMJJJxX qb8r0vN5E67Iai4bURr4za2G2BGCVaukvdvjEA78V3SwTakcDGXOc/Y+oCiXgp6j dcWLE/tdeP9bsd8dM8WI9jOsoIvXZOzpun5q8H+HbWZbj5xZOVGJooDMJCNb5Gi7 L42NyLOobR1eVUztwdl4AoVrXok69UI18I5+gQKv0RacOcVvPWGPEjzxclHHDiqH 1wmJruf26VaEtXpZGGpAN0Shbzx3Vex/G8B+EX8dqOI7iN83SqBLQMBL0zXu5QWs WxBJrZX3He5uw6AlliA9sg3p8mxAfK2XElp09Rd7ZgfqNApNQmp7WfTWFwWhUjY= =TfIG -----END PGP SIGNATURE-----
Hi, yes, I plan to implement it at the same place were lines are merged, that means, one merge for each sub division. Question is whether I find a way to do it without complex calculations, else it will slow down processing too much. Gerd Henning Scholland wrote
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Gerd, if this merging is done after style-processing, then it should be a great improvement without complications. Otherwise only polygons should be merged if all tags are equal.
Henning
Am 23.11.2013 16:25, schrieb GerdP:
Hi Andrzej,
for address search the data is saved with the roads, not with the polygons and poi are separate points, so I don't see a problem here. I did not yet start coding, as I still try to find a better algo for the bad angles in roads.
Gerd
popej wrote
Hi Gerd,
1) merge polygons with equal types etc. like in merge-lines algo, so that e.g. buildings that share walls are combined to one polygon > (without creating holes).
I would expect that many buildings have address tag which would make merging not advisable.
How merging would cooperate with option add-pois-to-areas?
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Possible-solution-for-deformed-polygons-tp578...
Sent from the Mkgmap Development mailing list archive at Nabble.com.
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux)
iQEcBAEBAgAGBQJSkNa2AAoJEPFgsWC7jOeTG+EIALR1DG4mMeJ1996r8ZMJJJxX qb8r0vN5E67Iai4bURr4za2G2BGCVaukvdvjEA78V3SwTakcDGXOc/Y+oCiXgp6j dcWLE/tdeP9bsd8dM8WI9jOsoIvXZOzpun5q8H+HbWZbj5xZOVGJooDMJCNb5Gi7 L42NyLOobR1eVUztwdl4AoVrXok69UI18I5+gQKv0RacOcVvPWGPEjzxclHHDiqH 1wmJruf26VaEtXpZGGpAN0Shbzx3Vex/G8B+EX8dqOI7iN83SqBLQMBL0zXu5QWs WxBJrZX3He5uw6AlliA9sg3p8mxAfK2XElp09Rd7ZgfqNApNQmp7WfTWFwWhUjY= =TfIG -----END PGP SIGNATURE-----
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Possible-solution-for-deformed-polygons-tp578... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd,
for address search the data is saved with the roads, not with the polygons and poi are separate points, so I don't see a problem here.
I'm interested if POI from polygons will be created before or after merging. Making them before merging seems better solution. I'd like to present house number over building area, see attached picture. House number is an attribute of building polygon. The same goes for building name. Off topic about address search: There exist better approach for point addressing, which is already used in some maps but not supported by mkgmap yet. The idea is to convert address point to a very short invisible road and then add this road to search index. This has advantage of precise location of address and also gives possibility to include house number with letters in street name. Maybe you could think about some kind of procedure, which would allow to convert poi to a line? Like an new option for mkgmap: add-lines-to-poi? -- Best regards, Andrzej
Hi Andrzej, popej wrote
for address search the data is saved with the roads, not with the polygons and poi are separate points, so I don't see a problem here.
I'm interested if POI from polygons will be created before or after merging. Making them before merging seems better solution.
Yes, POI are created much earlier (before style processing), in the style you decide what is done with the POI. The merge should happen much later. popej wrote
I'd like to present house number over building area, see attached picture. House number is an attribute of building polygon. The same goes for building name.
Off topic about address search: There exist better approach for point addressing, which is already used in some maps but not supported by mkgmap yet. The idea is to convert address point to a very short invisible road and then add this road to search index. This has advantage of precise location of address and also gives possibility to include house number with letters in street name.
Maybe you could think about some kind of procedure, which would allow to convert poi to a line? Like an new option for mkgmap: add-lines-to-poi?
Sounds interesting. I guess the algo for this is not very different from that which calculates the nearest road. Maybe WanMil knows more about this? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Possible-solution-for-deformed-polygons-tp578... Sent from the Mkgmap Development mailing list archive at Nabble.com.
I'd like to present house number over building area, see attached
picture. House number is an attribute of building polygon. The same goes for building name.
Off topic about address search: There exist better approach for point addressing, which is already used in some maps but not supported by mkgmap yet. The idea is to convert address point to a very short invisible road and then add this road to search index. This has advantage of precise location of address and also gives possibility to include house number with letters in street name.
Maybe you could think about some kind of procedure, which would allow to convert poi to a line? Like an new option for mkgmap: add-lines-to-poi? Sounds interesting. I guess the algo for this is not very different from that which calculates the nearest road. Maybe WanMil knows more about this?
So instead of using Garmins housenumber search you want to add a small road for each POI named with "${streetname} ${housenumber}'? Technically this sounds quite easy to implement. Some questions about that: * Wouldn't that blow up the index size? * Must each invisible road be connected to the rest of the road network? Otherwise I expect that Garmin is not able to route to the housenumbered streets and we get thousands of routing islands? * mkgmap would have to modify/create a TYP file with one invisible road type. Should this be processed by mkgmap or is that a task of the map generator to ensure that the additional road type is invisible? WanMil
Hi WanMil,
So instead of using Garmins housenumber search you want to add a small road for each POI named with "${streetname} ${housenumber}'?
Yes. Only including house number in street name could be limited to cases, where it contains non-numeric characters. And there should be a possibility to add house number numeric value to this street as a number for indexing, not only as a part of the name.
* Wouldn't that blow up the index size?
Probably, but it should work. I have an transparent overlay with nearly 2.5 millions of address POI and index img for Mapsource is about 30MB. Quite manageable value.
* Must each invisible road be connected to the rest of the road network? Otherwise I expect that Garmin is not able to route to the housenumbered streets and we get thousands of routing islands?
These roads don't have to be routable, only searchable. In my overlay I use roads type 0x13 with length of about 12m. Roads aren't connected to any network and whole overlay is not routable. GPS finds an address on non-routable road and then creates a route like to a POI, which is not placed on a road. See attached screen shoots from nuvi.
* mkgmap would have to modify/create a TYP file with one invisible road type. Should this be processed by mkgmap or is that a task of the map generator to ensure that the additional road type is invisible?
In my opinion mkgmap should provide generic tools and the rest should be left to map developer. -- Best regards, Andrzej
participants (5)
-
Andrzej Popowski -
demon.box -
GerdP -
Henning Scholland -
WanMil