Possible solution for deformed polygons

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Possible solution for deformed polygons

Gerd Petermann
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
Reply | Threaded
Open this post in threaded view
|

Re: Possible solution for deformed polygons

demon.box
...very interesting! I'll stay tuned...
Thanks!
--enrico
Reply | Threaded
Open this post in threaded view
|

Re: Possible solution for deformed polygons

popej
In reply to this post by Gerd Petermann
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Possible solution for deformed polygons

Gerd Petermann
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Possible solution for deformed polygons

osm-8
-----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
>
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
>
>
>
> -- View this message in context:
> http://gis.19327.n5.nabble.com/Possible-solution-for-deformed-polygons-tp5786064p5786952.html
>
>
Sent from the Mkgmap Development mailing list archive at Nabble.com.
> _______________________________________________ mkgmap-dev mailing
> list [hidden email]
> 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-----

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Possible solution for deformed polygons

Gerd Petermann
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
>
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
>
>
>
> -- View this message in context:
> http://gis.19327.n5.nabble.com/Possible-solution-for-deformed-polygons-tp5786064p5786952.html
>
>
Sent from the Mkgmap Development mailing list archive at Nabble.com.
> _______________________________________________ mkgmap-dev mailing
> list [hidden email] 
> 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-----

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Possible solution for deformed polygons

popej
In reply to this post by Gerd Petermann
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

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

hnym.png (59K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Possible solution for deformed polygons

Gerd Petermann
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
Reply | Threaded
Open this post in threaded view
|

Re: Possible solution for deformed polygons

WanMil
>> 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
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Possible solution for deformed polygons

popej
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

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

addr1.png (66K) Download Attachment