Re: [mkgmap-dev] default style improvements
Hi Ticker,
I often travel on bike in "nowhere land", where hotels and restaurants
are rare. So I think it is good to show both PoIs if a hotel contains a
restaurant. Of course, it would be more relevant to know how other users
of OSM Garmin maps think about this topic (I use my own style, so the
changes to the default style are not relevant for me).
A different point I'd like to suggest is a new line type for unpaved
highways (which are not tracks). Unpaved public highways may be not very
common in Europe, but they are rather normal in other areas of the world.
The fact that they are rendered like paved highways makes many mappers
think that it is useless to add this tag - and the little use of the
surface tag in turn makes map makers think that it does not matter...
Clouds of dust caused by other vehicles on that road or getting stuck in
a muddy quagmire are not great user experiences.
Treating them differently for routing purposes is a good step, but that
is not such visible to many users.
Regards,
Bernhard
Am 05.01.2019 um 18:18 schrieb Ticker Berkin:
Hi Gerd
I'd tried to get all the optical changes out of the way in the first 2
patches, but I missed a few and it seemed easier to fix them as I
spotted them.
This last patch covered about 25 issues. I think it might take a long
time to go through this process sequentially and, as it involves
changes to just 3 or 4 files, it will be confusing do them in parallel,
with multiple patches outstanding. I don't see any difficulty with
having dialogs in parallel about individual aspects in a patch, based
on my list of topics supplied with the first version of the patch.
Regarding polygons and area tag:
In the following, 'polygon' refers to a directly closed way or ways
from a multipolygon relation.
'lines' can test if is dealing with a polygon with:
... & (is_closed()=true | mkgmap:mp_created=true)
If an element needs to be rendered as a line possibly also a polygon it
needs a [... continue] in 'lines' in case it came from a closed way.
In 'polygons', one cannot assume that the element has not already been
rendered as a line.
The area= tag is for OSM mappers to influence the meaning of polygons;
mkgmap style should never set it.
The treatment of polygons being rendered as lines and/or polygons in
the absence of area=yes/no depends on the tag; for instance:
aeroway=runway is considered a line unless also has area=yes
highway=pedestrian always generates a line and, unless area=no, a
polygon. This is the OSM representation of a square/plaza, and, in many
cases, needs the routing given by the edge. The area tag is often
missing, so assumed as yes.
highway=footway always generates a line and, if area=yes, a polygon.
Again, the edge routing is might be needed. Some mappers use this for
walking area that are joined to other walkways/paths, but it shouldn't
be assumed to this, hence assumption of area=no.
It seems reasonably safe and clearer to omit the polygon test if also
testing area=yes. For instance, in 'lines'
aeroway=runway & area!=yes {name '${ref}'} [0x27 ...]
in 'polygons' the polygon test is irrelevant anyway, but it needs the
inverse of the additional clause in 'lines'
aeroway=runway & area=yes {name '${ref}'} [0x0e resolution 20]
Obviously, a non-polygon with area=yes doesn't get rendered at all.
Does this adequately explain my changes in this area?
At the moment, only elements with internet_access= can generate
multiple points. In your example of a hotel with a restaurant, I'd
rather have the hotel POI than the restaurant one. Many hotels have
restaurants, but most you wouldn't go out of your way to eat there or
they are often for guests only. The same is true of some of the
amenity/leisure/sport/tourist categories; they are more significant tha
n any restaurant they contain.
I must admit that this is an additional post-justification, I hadn't
thought of this when I moved the rules down.
Multiple POI from a single element, requiring massive reordering of the
sections in 'points' and lots of [... continue]s looks a different
problem that I don't want to address at the moment.
Regards
Ticker
On Sat, 2019-01-05 at 08:43 +, Gerd Petermann wrote:
Hi Ticker,
it would be easier to check if you would not mix simple optical
changes (additional/removed blanks) with functional changes ;)
I'd also prefer smaller patches, each one adressing only one problem.
This makes it easier to discuss the patch.
1) I do not yet understand the changes regarding area=yes and
multipolygons. Can you explain that, please?
2) Why are the rules for food POI moved behind e.g. tourism=hotel?
I think you often find OSM objects tagged with both
amenity=restaurant and tourism=hotel,
and I'd prefer to find both. Probably a case for continue ?
Gerd
Von: mkgmap-dev im Auftrag
von Ticker Berkin
Gesendet: Donnerstag, 3. Januar 2019 17:52
An: Development list for mkgmap
Betreff: Re: [mkgma
Re: [mkgmap-dev] default style improvements
Hi Ticker,
I think I understand the changes in the points file and in inc/accesss_country
and they look okay to me. I agree that it is better to have the hotel POI
for those cases where a point has both amenity=restaurant and tourism=hotel.
In polygons I don't understand some of the changes.
Dubious to me are those for
- aeroway
- shop now being rendered at res 24 instead of 22. Why?
- highway=pedestrian
- the rule
highway=* & (area=yes | mkgmap:mp_created=true) [0x05 resolution 22]
was removed. In Italy and probably other countries as well I see many
highway=residential + area=yes or highway=service+area=yes as an alternative
to map place=square (which is quite new)
Most of the changes in lines look OK to me.
- I don't like all the changes reg. area, see also Lorenzos comment.
- I think highway=access_ramp is equivalent to highway=footway, see
https://wiki.openstreetmap.org/wiki/Proposed_features/Access_Ramp
- not sure why you set bicycle=no for highway=trail?
- You see tmp:stopMopUp=yes in some rules but the rules that would evaluate
that tag are commented. I'd rather remove all.
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
Gesendet: Samstag, 5. Januar 2019 18:18
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] default style improvements
Hi Gerd
I'd tried to get all the optical changes out of the way in the first 2
patches, but I missed a few and it seemed easier to fix them as I
spotted them.
This last patch covered about 25 issues. I think it might take a long
time to go through this process sequentially and, as it involves
changes to just 3 or 4 files, it will be confusing do them in parallel,
with multiple patches outstanding. I don't see any difficulty with
having dialogs in parallel about individual aspects in a patch, based
on my list of topics supplied with the first version of the patch.
Regarding polygons and area tag:
In the following, 'polygon' refers to a directly closed way or ways
from a multipolygon relation.
'lines' can test if is dealing with a polygon with:
... & (is_closed()=true | mkgmap:mp_created=true)
If an element needs to be rendered as a line possibly also a polygon it
needs a [... continue] in 'lines' in case it came from a closed way.
In 'polygons', one cannot assume that the element has not already been
rendered as a line.
The area= tag is for OSM mappers to influence the meaning of polygons;
mkgmap style should never set it.
The treatment of polygons being rendered as lines and/or polygons in
the absence of area=yes/no depends on the tag; for instance:
aeroway=runway is considered a line unless also has area=yes
highway=pedestrian always generates a line and, unless area=no, a
polygon. This is the OSM representation of a square/plaza, and, in many
cases, needs the routing given by the edge. The area tag is often
missing, so assumed as yes.
highway=footway always generates a line and, if area=yes, a polygon.
Again, the edge routing is might be needed. Some mappers use this for
walking area that are joined to other walkways/paths, but it shouldn't
be assumed to this, hence assumption of area=no.
It seems reasonably safe and clearer to omit the polygon test if also
testing area=yes. For instance, in 'lines'
aeroway=runway & area!=yes {name '${ref}'} [0x27 ...]
in 'polygons' the polygon test is irrelevant anyway, but it needs the
inverse of the additional clause in 'lines'
aeroway=runway & area=yes {name '${ref}'} [0x0e resolution 20]
Obviously, a non-polygon with area=yes doesn't get rendered at all.
Does this adequately explain my changes in this area?
At the moment, only elements with internet_access= can generate
multiple points. In your example of a hotel with a restaurant, I'd
rather have the hotel POI than the restaurant one. Many hotels have
restaurants, but most you wouldn't go out of your way to eat there or
they are often for guests only. The same is true of some of the
amenity/leisure/sport/tourist categories; they are more significant tha
n any restaurant they contain.
I must admit that this is an additional post-justification, I hadn't
thought of this when I moved the rules down.
Multiple POI from a single element, requiring massive reordering of the
sections in 'points' and lots of [... continue]s looks a different
problem that I don't want to address at the moment.
Regards
Ticker
On Sat, 2019-01-05 at 08:43 +, Gerd Petermann wrote:
> Hi Ticker,
>
> it would be easier to check if you would not mix simple optical
> changes (additional/removed blanks) with functional changes ;)
> I'd also prefer smaller patches, each one adressing only one problem.
> This makes it easier to discuss the patch.
>
> 1) I do not yet understand the changes regarding area=yes and
> multipolygons. Can you explain that, please?
> 2) Why are the rules for food POI moved behind e.g. tourism=hotel?
> I think you often find OSM objects tagged with both
> amenity=restaurant and tourism=hotel
Re: [mkgmap-dev] default style improvements
Hi Lorenzo I know that the OSM definition says square should have area=yes, but I find a vast number where there is no area tag and they seem to be square/piazza, eg https://www.openstreetmap.org/relation/5174171 With Italy data from July 2018, I get about 5000 highway=pedestrian polygons without an area tag, and, from a small sample, about 1 in 3 look like piazza. The only effect is that a polygon is generated, it doesn't effect routes. I prefer to see the possible square rendered. Ticker On Sun, 2019-01-06 at 00:26 +0100, Lorenzo Mastrogiacomi wrote: > Il giorno sab, 05/01/2019 alle 17.18 +, Ticker Berkin ha scritto: > > > > > > highway=pedestrian always generates a line and, unless area=no, a > > polygon. This is the OSM representation of a square/plaza, and, in > > many > > cases, needs the routing given by the edge. The area tag is often > > missing, so assumed as yes. > > > > Not really Ticker, highway=pedestrian is a linear feature in osm like > other highway=* tags used for road ways. area=yes is required to make > it an area. > > > Lorenzo > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements
Ticker Berkin writes: > I know that the OSM definition says square should have area=yes, but I > find a vast number where there is no area tag and they seem to be > square/piazza, eg > > https://www.openstreetmap.org/relation/5174171 > > With Italy data from July 2018, I get about 5000 highway=pedestrian > polygons without an area tag, and, from a small sample, about 1 in 3 > look like piazza. > > The only effect is that a polygon is generated, it doesn't effect > routes. I prefer to see the possible square rendered. I see this as part of a larger issue: when the OSM data is wrong, but it's possible to figure out what it should have been, should those errors be fixed up in map generation? A compromise might be to explicitly note the workaround in the style file, rather than making it seem like the style is correctly interpreting the data. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements
Bernhard Hiller writes: > I often travel on bike in "nowhere land", where hotels and restaurants > are rare. So I think it is good to show both PoIs if a hotel contains > a restaurant. Of course, it would be more relevant to know how other > users of OSM Garmin maps think about this topic (I use my own style, > so the changes to the default style are not relevant for me). There are two issues; one is display, and the other is search. I think ti's pretty important that "show me cafes and restaurants nearby" find hotel restaurants (that are open to non-guests). I don't think it's quite as important that they both show up. But when zoomed all the way in, it would be nice. Plus, mappers often put the hotel POI on the building and a separate restuarant POI where the restaurant is. > A different point I'd like to suggest is a new line type for unpaved > highways (which are not tracks). Unpaved public highways may be not > very common in Europe, but they are rather normal in other areas of > the world. > The fact that they are rendered like paved highways makes many mappers > think that it is useless to add this tag - and the little use of the > surface tag in turn makes map makers think that it does not > matter... Clouds of dust caused by other vehicles on that road or > getting stuck in a muddy quagmire are not great user experiences. > Treating them differently for routing purposes is a good step, but > that is not such visible to many users. Agreed that unpaved public roads should have a different symbol. (Even where I am, in Massachusetts, US, they have a significant existence.) (I think the real reason they don't exist in the UK is that it's too wet and they would always be muddy. I drove on some roads there that are so minor that almost certainly would not have been paved in the US. And this UK non-existence of unpaved real roads has led to some distortion of their representation in OSM.) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements
Hi Gerd see embedded answers Regards Ticker On Sun, 2019-01-06 at 09:11 +, Gerd Petermann wrote: > Hi Ticker, > > I think I understand the changes in the points file and in > inc/accesss_country and they look okay to me. I agree that it is > better to have the hotel POI > for those cases where a point has both amenity=restaurant and > tourism=hotel. > > In polygons I don't understand some of the changes. > Dubious to me are those for > - aeroway aeroway=runway/taxiway/taxilane are rendered as 0x27="Runway" lines unless they have area=yes, in which case they are rendered as 0x0e="Aircraft Road" polygons. Circular (ie closed ways) taxiways are a well defined concept and shouldn't need area=no. This handling seemed to fit with some of the examples I looked at. > - shop now being rendered at res 24 instead of 22. Why? I changed this because most shops are at the same scale as building/cafe/restaurant, which are at res 24. I don't have a strong opinion on this. > - highway=pedestrian Not sure what you are asking here. The most significant change was to render as routable lines regardless of being closed/multipolygons/area tag. (ie giving square/plaza edge routing). The other changes were to continue but avoid any possible highway mop-up so that always get to 'polygons' and there render as square/plaza unless area=no (but have this rule after place=square rule) > - the rule > highway=* & (area=yes | mkgmap:mp_created=true) [0x05 resolution 22] > was removed. In Italy and probably other countries as well I see many > highway=residential + area=yes or highway=service+area=yes as an > alternative > to map place=square (which is quite new) This rule is wrong in many ways! It generates a "Parking Lot" as a highway=* mop-up. There shouldn't be a difference in the handling of polygons derived from multiPolygon or simple closed ways. I added the explicit: # other highways that have area=yes are probably parking lots, eg services/rest_area (highway=services | highway=rest_area) & area!=no [0x05 resolution 22] but, from a recent post, it is thought that highway=services is better treated as a retail area and I plan to do this in a future change. If you think other highway types (ie service/residential) that have area=yes should also generate a square/plaza then I'm happy to include this. > Most of the changes in lines look OK to me. > - I don't like all the changes reg. area, see also Lorenzos comment. Are you referring to area= changes other than highway=pedestrian as per Lorenzos comments? Just seen Greg's comments and maybe the answer is to annotate the rule when it trying to do the best with bad data. > - I think highway=access_ramp is equivalent to highway=footway, see > https://wiki.openstreetmap.org/wiki/Proposed_features/Access_Ramp I can't remember the example I looked at but it seemed more like a service road. However, as there is this proposal, I'll change it to footway. > - not sure why you set bicycle=no for highway=trail? This tag is not well defined, but its wiki page: https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtrail says should not assume that it cycleable > - You see tmp:stopMopUp=yes in some rules but the rules that would > evaluate that tag are commented. I'd rather remove all. Although the rules that test it are commented, one is a diagnostic to show unhandled highway= and the other is the one that generates a routable line. Although the opinion seems to be that these shouldn't be shown, I feel strongly that they should and will continue to do so on my maps. If other people want the same they just uncomment the line. > Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements
Il giorno dom, 06/01/2019 alle 12.45 +, Ticker Berkin ha scritto: > Hi Lorenzo > > I know that the OSM definition says square should have area=yes, but > I > find a vast number where there is no area tag and they seem to be > square/piazza, eg > > https://www.openstreetmap.org/relation/5174171 This is a multipolygon. The current rule to handle this with the mkgmap:mp_created tag is fine for a default style in my opinion. > > With Italy data from July 2018, I get about 5000 highway=pedestrian > polygons without an area tag, and, from a small sample, about 1 in 3 > look like piazza. > The only effect is that a polygon is generated, it doesn't effect > routes. I prefer to see the possible square rendered. > I don't. 1 in 3 correct is not so good :) > Ticker > > Lorenzo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements
Hi all, Just to make that clear: A way with highway=pedestrian is that is not closed will only be treated by polygon rules when it is part of a multipolygon. So, the question is how many of those don't have an area=yes and how many of the latter probably should have area=yes. Gerd Von: mkgmap-dev im Auftrag von Lorenzo Mastrogiacomi Gesendet: Sonntag, 6. Januar 2019 17:46 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements Il giorno dom, 06/01/2019 alle 12.45 +, Ticker Berkin ha scritto: > Hi Lorenzo > > I know that the OSM definition says square should have area=yes, but > I > find a vast number where there is no area tag and they seem to be > square/piazza, eg > > https://www.openstreetmap.org/relation/5174171 This is a multipolygon. The current rule to handle this with the mkgmap:mp_created tag is fine for a default style in my opinion. > > With Italy data from July 2018, I get about 5000 highway=pedestrian > polygons without an area tag, and, from a small sample, about 1 in 3 > look like piazza. > The only effect is that a polygon is generated, it doesn't effect > routes. I prefer to see the possible square rendered. > I don't. 1 in 3 correct is not so good :) > Ticker > > Lorenzo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements
Hi Gerd Not sure what you mean here. Only complete polygons, either from closed ways or generated by multipolygon get to be interpreted by 'polygons' style processing. Ticker On Sun, 2019-01-06 at 16:58 +, Gerd Petermann wrote: > Hi all, > Just to make that clear: A way with highway=pedestrian is that is > not closed will only be treated by polygon > rules when it is part of a multipolygon. > So, the question is how many of those don't have an area=yes and how > many of the latter probably should have area=yes. > > Gerd > > > Von: mkgmap-dev im Auftrag > von Lorenzo Mastrogiacomi > Gesendet: Sonntag, 6. Januar 2019 17:46 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] default style improvements > > Il giorno dom, 06/01/2019 alle 12.45 +, Ticker Berkin ha scritto: > > Hi Lorenzo > > > > I know that the OSM definition says square should have area=yes, > > but > > I > > find a vast number where there is no area tag and they seem to be > > square/piazza, eg > > > > https://www.openstreetmap.org/relation/5174171 > > > This is a multipolygon. > The current rule to handle this with the mkgmap:mp_created tag is > fine > for a default style in my opinion. > > > > > > With Italy data from July 2018, I get about 5000 highway=pedestrian > > polygons without an area tag, and, from a small sample, about 1 in > > 3 > > look like piazza. > > > The only effect is that a polygon is generated, it doesn't effect > > routes. I prefer to see the possible square rendered. > > > > I don't. 1 in 3 correct is not so good :) > > > > > Ticker > > > > > > > Lorenzo > > > > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements
Hi I don't see anything in the OSM definition of a square that requires it to come from a multipolygon relation https://wiki.openstreetmap.org/wiki/Tag:highway%3Dpedestrian Ticker On Sun, 2019-01-06 at 17:46 +0100, Lorenzo Mastrogiacomi wrote: > Il giorno dom, 06/01/2019 alle 12.45 +, Ticker Berkin ha scritto: > > Hi Lorenzo > > > > I know that the OSM definition says square should have area=yes, > > but > > I > > find a vast number where there is no area tag and they seem to be > > square/piazza, eg > > > > https://www.openstreetmap.org/relation/5174171 > > > This is a multipolygon. > The current rule to handle this with the mkgmap:mp_created tag is > fine > for a default style in my opinion. > > > > > > With Italy data from July 2018, I get about 5000 highway=pedestrian > > polygons without an area tag, and, from a small sample, about 1 in > > 3 > > look like piazza. > > > The only effect is that a polygon is generated, it doesn't effect > > routes. I prefer to see the possible square rendered. > > > > I don't. 1 in 3 correct is not so good :) > > > > > Ticker > > > > > > > Lorenzo > > > > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements
Hi Ticker, yes, you are right. I guess I thought about the special case where the mp-code would try to close an unclosed ring. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Sonntag, 6. Januar 2019 18:34 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style improvements Hi Gerd Not sure what you mean here. Only complete polygons, either from closed ways or generated by multipolygon get to be interpreted by 'polygons' style processing. Ticker On Sun, 2019-01-06 at 16:58 +, Gerd Petermann wrote: > Hi all, > Just to make that clear: A way with highway=pedestrian is that is > not closed will only be treated by polygon > rules when it is part of a multipolygon. > So, the question is how many of those don't have an area=yes and how > many of the latter probably should have area=yes. > > Gerd > > > Von: mkgmap-dev im Auftrag > von Lorenzo Mastrogiacomi > Gesendet: Sonntag, 6. Januar 2019 17:46 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] default style improvements > > Il giorno dom, 06/01/2019 alle 12.45 +, Ticker Berkin ha scritto: > > Hi Lorenzo > > > > I know that the OSM definition says square should have area=yes, > > but > > I > > find a vast number where there is no area tag and they seem to be > > square/piazza, eg > > > > https://www.openstreetmap.org/relation/5174171 > > > This is a multipolygon. > The current rule to handle this with the mkgmap:mp_created tag is > fine > for a default style in my opinion. > > > > > > With Italy data from July 2018, I get about 5000 highway=pedestrian > > polygons without an area tag, and, from a small sample, about 1 in > > 3 > > look like piazza. > > > The only effect is that a polygon is generated, it doesn't effect > > routes. I prefer to see the possible square rendered. > > > > I don't. 1 in 3 correct is not so good :) > > > > > Ticker > > > > > > > Lorenzo > > > > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] default style improvements
It's not what I meant. The example you provided is a multipolygon relation and multipolygons are always areas regardless if area=yes is set or not. So this is not a valid example, actually I can not find one really evident of missing area=yes on pedestrian areas. Lorenzo Il giorno dom, 06/01/2019 alle 17.37 +, Ticker Berkin ha scritto: > Hi > > I don't see anything in the OSM definition of a square that requires > it > to come from a multipolygon relation > > https://wiki.openstreetmap.org/wiki/Tag:highway%3Dpedestrian > > > Ticker > > On Sun, 2019-01-06 at 17:46 +0100, Lorenzo Mastrogiacomi wrote: > > Il giorno dom, 06/01/2019 alle 12.45 +, Ticker Berkin ha > > scritto: > > > Hi Lorenzo > > > > > > I know that the OSM definition says square should have area=yes, > > > but > > > I > > > find a vast number where there is no area tag and they seem to be > > > square/piazza, eg > > > > > > https://www.openstreetmap.org/relation/5174171 > > > > > > > > > This is a multipolygon. > > The current rule to handle this with the mkgmap:mp_created tag is > > fine > > for a default style in my opinion. > > > > > > > With Italy data from July 2018, I get about 5000 > > > highway=pedestrian > > > polygons without an area tag, and, from a small sample, about 1 > > > in > > > 3 > > > look like piazza. > > > The only effect is that a polygon is generated, it doesn't effect > > > routes. I prefer to see the possible square rendered. > > > > > > > I don't. 1 in 3 correct is not so good :) > > > > > > > > > Ticker > > > > > > > > > > > > Lorenzo > > > > > > > > > > ___ > > mkgmap-dev mailing list > > mkgmap-dev@lists.mkgmap.org.uk > > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
