Hi Gerd It can only be: ${tagname|filter:args} or ${tagname|filter1:"arg with spaces"} and, for the subst filter, the from=>to counts as a single arg. In the example: ... '${ref|subst: =>} ${mkgmap:dest_hint|subst:;=> |subst:/=> }' spaces are insignificant either side of the first | and before the : but are significant after the : and before subsequent |. The style manual says: If the argument contains spaces or symbols it should be quoted. For backward compatibility, most cases where you have spaces or symbols do not actually need to be quoted, however we would recommend that you do for clarity. If you need a pipe symbol or a closing curly backet, then you must use quotes. Ticker On Thu, 2020-07-23 at 10:40 +0000, Gerd Petermann wrote:

Hi Ticker,

I am not a style guru, but I think the quotes for the subst function are even more confusing. If you use quotes I would suggest something like ${destination:ref|subst:" " => ""} instead of ${destination:ref|subst: =>} if that really gives the same result.

Gerd

Hi Ticker, I agree with Gerd that creating a route around all car parks may not be ideal. I fear that in most of the cases it will create extra lines when they aren't necessary . When an osm mapper is not concerned about  routing across car parks ,   it seems only in certain cases paths stop on the outline of a car park and in my experience some 'ends'  just get plonked on top of the carpark ! However, as with pedestrian areas, unfortunately , there are other polygons, ie parks ,golf courses, grass lands, which are equally problematic. Some plot highway=virtual to ensure some routing - although this gets frowned upon by some. Ideally mkgmap  identifies ends of highways inside a polygon and joins them, but that might also be unsatisfactory. Anyway, thanks for your great efforts to bring this style  up  to date ! Nick On 25/07/2020 09:28, Gerd Petermann wrote:

Hi Ticker,

ok, most of the changes look plausible to me, but I see no need to add the lines for razed / disued / abandoned etc. railways. I would comment these two lines: abandoned:railway=* | demolished:railway=* | removed:railway=* | razed:railway=* | was:railway=* | historic:railway=* {add railway=lifecyclePrefix} railway=* & railway!=miniature & railway!=proposed & tunnel!=yes & highway!=* & is_closed()=false [0x19 resolution 22]

I am also not sure about the routable lines for amenity=parking. Even with the test reg. connected this probably creates lots of routing islands. As a mapper, I've never cared to connect those areas to the road network, but I know that other mappers do this. Is it meant to improve pedestrian routing?

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 23. Juli 2020 17:46 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style lines enhancements

Hi Gerd

It can only be: ${tagname|filter:args} or ${tagname|filter1:"arg with spaces"}

and, for the subst filter, the from=>to counts as a single arg.

In the example: ... '${ref|subst: =>} ${mkgmap:dest_hint|subst:;=> |subst:/=> }' spaces are insignificant either side of the first | and before the : but are significant after the : and before subsequent |.

The style manual says: If the argument contains spaces or symbols it should be quoted. For backward compatibility, most cases where you have spaces or symbols do not actually need to be quoted, however we would recommend that you do for clarity. If you need a pipe symbol or a closing curly backet, then you must use quotes.

Ticker

On Thu, 2020-07-23 at 10:40 +0000, Gerd Petermann wrote:

...

Hi Ticker,

I am not a style guru, but I think the quotes for the subst function are even more confusing. If you use quotes I would suggest something like ${destination:ref|subst:" " => ""} instead of ${destination:ref|subst: =>} if that really gives the same result.

Gerd

---

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

Hi Ticker, reg. car parks: In what scenario do the additional routable ways help? Do you think of a car driver who stops there and tries to calculate a pedestrian route to a place which is not yet in sight? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 27. Juli 2020 17:32 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style lines enhancements Hi Gerd & Nick I'll comment out the rules that give "Course of old Railway" Concerning footways around car parks: I'd used: set mkgmap:set_unconnected_type=none; set mkgmap:set_semi_connected_type=none; so that if the footway didn't connect 2 other highways (road or path) it would be discarded and not create any routing islands. When walking in some areas, I've found mappers had frequently run footpaths up to car parks, but not joined them to the road/parking -alley or other footpaths, so routing that spans the car park fails. The problem is also common in town center car parks where the car park is just off the High Street and can be accessed on foot by various alleys. Other areas (village greens, parks etc) can be problematic, but greens are often surrounded by roads and parks & golf courses normally have the footpaths explicitly mapped. Having some functionality that join unconnected ends of highways within a polygon would be a better solution as Nick says. My solution relies on mappers at least joining the path to the edge of the car park; Ticker On Sat, 2020-07-25 at 11:11 +0100, nick wrote:

Hi Ticker,

I agree with Gerd that creating a route around all car parks may not be ideal.

I fear that in most of the cases it will create extra lines when they aren't necessary .

When an osm mapper is not concerned about routing across car parks ,

it seems only in certain cases paths stop on the outline of a car park and in my experience some 'ends' just get plonked on top of the carpark !

However, as with pedestrian areas, unfortunately , there are other polygons, ie parks ,golf courses, grass lands, which are equally problematic.

Some plot highway=virtual to ensure some routing - although this gets frowned upon by some.

Ideally mkgmap identifies ends of highways inside a polygon and joins them, but that might also be unsatisfactory.

Anyway, thanks for your great efforts to bring this style up to date !

Nick

On 25/07/2020 09:28, Gerd Petermann wrote:

...

Hi Ticker,

ok, most of the changes look plausible to me, but I see no need to add the lines for razed / disued / abandoned etc. railways. I would comment these two lines: abandoned:railway=* | demolished:railway=* | removed:railway=* | razed:railway=* | was:railway=* | historic:railway=* {add railway=lifecyclePrefix} railway=* & railway!=miniature & railway!=proposed & tunnel!=yes & highway!=* & is_closed()=false [0x19 resolution 22]

I am also not sure about the routable lines for amenity=parking. Even with the test reg. connected this probably creates lots of routing islands. As a mapper, I've never cared to connect those areas to the road network, but I know that other mappers do this. Is it meant to improve pedestrian routing?

Gerd

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi all, I have two reasons why I don't like to create routable ways for objects which are not meant to be routable ways: 1) Some mappers get it wrong and start to change OSM data to the worse because "mkgmap expects it like that" 2) If a routable way is not mapped as such or not connected correctly in OSM it should be fixed in OSM. Besides I doubt that the additional ways help if you are on the car park and start to calculate a route. IIGTR It might tell you to walk around the car park instead of drawing a straight line to the next highway. Gerd ________________________________________ Von: Greg Troxel <gdt@lexort.com> Gesendet: Montag, 27. Juli 2020 17:55 An: Gerd Petermann Cc: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style lines enhancements Gerd Petermann <gpetermann_muenchen@hotmail.com> writes:

Hi Ticker,

reg. car parks: In what scenario do the additional routable ways help? Do you think of a car driver who stops there and tries to calculate a pedestrian route to a place which is not yet in sight?

Gerd

All a good discussion about OSM, but I wonder what mkgmap should do. If a person can reasonably walk places, the ways should be connected and if not it is a map bug. Those bugs as Ticker describes are relatively frequent. As I see it the real question is whether mkgmap should make assumptions that certain ways are connected when they aren't connected in the database. The default behavior would be to just process what's there, with the result that routing is sometimes not so great, in that it leaves out things you actually can do. But the most interesting such things can' be guessed.

I create foot routable (but not vehicle routable) ways around car parks in my style (I don't use the default style). This allows pedestrian routing around the car park in cases like https://www.openstreetmap.org/directions?engine=graphhopper_foot&route=42.45 938%2C-71.35133%3B42.45856%2C-71.35058 which is a few yards away from the previous example. It is common for footpaths to start at the edge of a car park and in my opinion it is incorrect to add to OSM a non-existent footpath across a car park purely for the purposes of routing. Regards, Mike -----Original Message----- From: Greg Troxel [mailto:gdt@lexort.com] Sent: 27 July 2020 17:15 To: Gerd Petermann <gpetermann_muenchen@hotmail.com> Cc: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] default style lines enhancements Gerd Petermann <gpetermann_muenchen@hotmail.com> writes:

Hi all,

I have two reasons why I don't like to create routable ways for objects which are not meant to be routable ways: 1) Some mappers get it wrong and start to change OSM data to the worse because "mkgmap expects it like that"

Didn't think of that but strongly agreed.

2) If a routable way is not mapped as such or not connected correctly in OSM it should be fixed in OSM.

Completely agreed and that's what I meant to say.

Besides I doubt that the additional ways help if you are on the car park and start to calculate a route. IIGTR It might tell you to walk around the car park instead of drawing a straight line to the next highway.

What I meant is that foot routes like this are found https://www.openstreetmap.org/directions?engine=graphhopper_foot&route=42.46 043%2C-71.35108%3B42.46162%2C-71.34935 but that's a case of correct OSM data, as it should be. I think Ticker is saying that sometimes the footpath is joined to the amenity=parking polygon, instead of the service road, and correct routing does not magically jump over that gap.

Hi Greg, In the case I showed, I would probably have tagged it as you mention in view A as there is a parking aisle drawn. However, many small car parks do not have parking aisles, and in that case I would not probably draw a footpath right across the car park and would go for view B. As one can normally walk anywhere on a car park, by definition you can also walk around the edge to any connected point, hence it seems reasonable to me to add the car park perimeter as foot routable. If you use Foot (OSRM) instead of Foot (GraphHopper) for OSM routing, it does take you around the edge of the car park. For vehicles, I would only expect a car park to be a start point or an end point, so it does not need to be routable. In the case of a fence, the route around the edge is a routing artefact and you would actually walk across it, so if two paths join a car park you should be able to walk between them whether or not there is a fence around the edge. Perhaps a better solution would be to join each point that stops at the edge of a car park together with a routable way. A new option to handle this? Regards, Mike -----Original Message----- From: Greg Troxel [mailto:gdt@lexort.com] Sent: 27 July 2020 17:53 To: Mike Baggaley <mike@tvage.co.uk> Cc: 'Gerd Petermann' <gpetermann_muenchen@hotmail.com>; 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] default style lines enhancements "Mike Baggaley" <mike@tvage.co.uk> writes:

I create foot routable (but not vehicle routable) ways around car parks in my style (I don't use the default style). This allows pedestrian routing around the car park in cases like

https://www.openstreetmap.org/directions?engine=graphhopper_foot&route=42.45

938%2C-71.35133%3B42.45856%2C-71.35058 which is a few yards away from the previous example. It is common for footpaths to start at the edge of a car park and in my opinion it is incorrect to add to OSM a non-existent footpath across a car park purely for the purposes of routing.

That's really something to bring up on tagging. As I see it there are two views: A) one should continue the footpath in a way that represents how a person could walk to connect it to the parking aisles (that they also can walk on). While there isn't something that is visibibly a footpath, there is in fact a place you can continue to walk from the edge of the lot to the parking aisle/driveway. B) Really there is a surface and one can walk anywhere there isn't a car parked, and thus the footpath should only represent the footpath and be joined to the edge. Thus the carpark is really a routable pedestrian area. This should either be the default or it should be tagged this way. Two comments: I think A is the majority view in OSM by a wide margin. In B, you have to somehow deal with a fence around the lot, and be careful not to create routable ways that can't be traversed. In this case, there is a fence on the SW side (not shown in OSM probably) but I think not on the NW side.

Hi all In some major walking areas there are networks of paths with a few car parks around the edge, normally set 100m or so into the park/woods. The free maps one can obtain show suggested trails and these trails often cross multiple car parks. The maps probably don't show a path within the car park and there is no physical manifestation of it. Without "paths around car park", if I try to use my device to generate a walking route to some feature in the area (or back to the start), it will probably generate a route that leaves the area, gets onto the closest road, and re-enters elsewhere. Or it might give a "Route Calculation Error" because paths closest to the start or end are not connected to the rest of the network. With the data as it stands, for sensible routes in the above situation and others as expressed in my earlier email, mkgmap needs to generate footways that join up all ways that lead into the car park with a footway. With the current technology this can be done with circumference footway and mkgmap:set_{semi_/un}connected_type provide a really good way of not doing this where the footway won't solve any routing issue and might cause routing island problems. I wouldn't object if OSM mappers joined all paths and the entrance road/parking aisles within the car park and maybe there should be a policy to do this and then there is no problem. However, there is a good argument that the correct OSM mapping is to show paths exactly as they are and not have to invent and add 'virtual' bits of footpath just to keep routing engines working sensibly because "mkgmap expects it like that". Other things that have been mentioned: - What about a path that runs up to or along the side of a car park but there is no access between them, eg an enclosed car park with a road along-side. I'd say that this is just incorrect mapping if the car park shares a node with the road but there is a barrier between. - If starting within the car park, the route might tell you to walk around the edge rather that direct to the highway. Yes and no; it will plot a route to the closest edge and then to the best exit for the final destination; It should be obvious to the GPS user that they can just walk directly to the best exit. Without the change the only option you might get is onto the road network which could be entirely wrong. Ticker

ael <witwall3@disroot.org> writes:

Not just mkgmap. It is a general problem. Maybe OSM should introduce a new relation "connected"? That is one or more ways and/or points could be members implying that it is possible to navigate (perhaps directly) between any of them. That would solve many of the problems for all routers. This idea needs expansion: a tag on the relation would specify the mode of transport, although I guess this would be mainly foot. Likewise, some sort of seasonal tag would be useful. But most of those already exist for ways, so I suppose those could be just be applied to the relation as well.

Right now we represent this with ways, and they have well-defined semantics. This seems comlicated and would need implementation in many data consumers.

Just musing out loud. If it seems sensible, maybe a proposal on the tagging list?

Feel free; I don't expect that to go well. I do think, however, that mkgmap should simply interpret existing OSM tagggin conventions, guided by analyzing how the broader set of routers treat things. (mkgmap+garmin is a router.)

ael <witwall3@disroot.org> writes:

...

Feel free; I don't expect that to go well.

As far as I can see, the current discussion is just a special case of a general problem with OSM. Consider a park with grass cover with open access, or even just an area of, say open access moorland where it is possible & sensible to walk anywhere. As far as I know, all the OSM routers will fail to construct a route across such a place (presumably a straight line) in the absence of an explicit way of some sort.

Adding a relation of the sort I suggested which would be verifiable and objective would solve the problem. Is there a better solution?

I didn't say your idea made no sense. I said that I didn't expect the discussion to go well :-) But don't let my guess stop you. I prefer soemthing like a polygon of type highway=path that covers the free-routable space, to which regular ways are connected to. Sort of the same thing, but without adding relations in, and treating free-routable areas as first-class items similar to line-routable ways.

Of course, routers would not pick this up immmediately. As for mkgmap, I see that the Garmin firmware probably needs to support it somehow. Are we sure that Garmin doesn't have something that can interpolate between routing points? I guess that navit could probably be extended to do this sort of thing.

My impression is that people synthesize a bunch of diagonals when there is an erea, for routers that don't do areas.

Hi Concerning car parks - the problem is that, in the existing OSM data, sometimes some of the footways to the car park and the access road/aisles don't join. The OSM solution to this is to join them; it is considered a mapping error for them not to be joined. A different solution that also requires finding and editing every car park that has this problem is not required. I want to put something into the default style that handles the routing issue in some of these situations. It doesn't require any changes to anything but default:lines and, I think, won't cause additional problems. My solution doesn't handle footpaths that terminate in or (run) on the car park edge but don't share a node. Ticker

On Tue, 2020-07-28 at 08:52 -0400, Greg Troxel wrote:

Ticker Berkin <rwb-mkgmap@jagit.co.uk> writes:

...

With the data as it stands, for sensible routes in the above situation and others as expressed in my earlier email, mkgmap needs to generate footways that join up all ways that lead into the car park with a footway. With the current technology this can be done with circumference footway and mkgmap:set_{semi_/un}connected_type provide a really good way of not doing this where the footway won't solve any routing issue and might cause routing island problems.

And it will generate paths that may not actually exist, or might be signed no trespassing. Gerd has said that he doesn't want to synthesize data that isn't in OSM, and I think this is wise.

It is a public car park; you need to be able to walk to or from any point as that's where your car might be.

...

I wouldn't object if OSM mappers joined all paths and the entrance road/parking aisles within the car park and maybe there should be a policy to do this and then there is no problem.

There is broad consensus that this is the right thing to do. Editors warn about "way end close to other way".

...

However, there is a good argument that the correct OSM mapping is to show paths exactly as they are and not have to invent and add 'virtual' bits of footpath just to keep routing engines working sensibly because "mkgmap expects it like that".

It is not about mkgmap. It is pretty much all routers. A path represents "you can travel along this way with this mode and this access". That's exactly what is going on, at a simple level. At a more complicated level, you can claim that the parking lot is pedestrian way, but that isn't really true. It's really that the thing that looks like a path comes to the edge of the path and there is a way to continue walking onto pavement to get to the space between aisles.

I'm trying not to imagine anything that looks like a path, but I would consider it like a pedestrian area where you can walk anywhere reasonable within it. There isn't a method of representing this in a Garmin .img such that routing works in the expected way, and the next best thing, that solves the routing problems and that we can do with current technology, is to generate a foot routable navigation around the circumference. If this was to use an invisible line would you object less?

If there is a sidewalk around the lot, then map it. And add ways to get from sidewalk to the middle.

I wouldn't want to add more than the minimum extra routes. The circumference is this minumum number. Routes to the middle are not the problem, but, as Gerd points out, having mkgmap decide where the middle is could be very wrong.

...

Other things that have been mentioned:

- What about a path that runs up to or along the side of a car park but there is no access between them, eg an enclosed car park with a road along-side. I'd say that this is just incorrect mapping if the car park shares a node with the road but there is a barrier between.

It is almost always (alwyas?) incorrect to have a parking lot share a node with a road. That would imply that the parking lot beings on the road centerline.

...

- If starting within the car park, the route might tell you to walk around the edge rather that direct to the highway. Yes and no; it will plot a route to the closest edge and then to the best exit for the final destination; It should be obvious to the GPS user that they can just walk directly to the best exit. Without the change the only option you might get is onto the road network which could be entirely wrong.

with correct mapping, you usually get a sensible route along parking aisles.

The debate about what is correct mapping is open. I think mkgmap/default style should provide the best routing given the existing data.

I really do not understand the resistance to making the map data represent what you can do on the ground. It seems really obvious that this is sensible, and that is the majority view within osm tagging.

I don't have any objection to this, but it doesn't work with what I often see on the ground, which is: 1/ an area where (sometimes free-format) parking is allowed. 2/ an access track that runs to the boundary that allows vehicles and links to the road system. 3/ multiple foot paths that start on the boundary of the car park. Ticker

Hi Greg I was only going to join up paths that share a node with the edge of the car park - I wasn't going to do anything with paths that just go near the edge. I disagree with the assertion that there are always parking isles and if these don't exist in the OSM data for a car park it has not been mapped correctly and should be fixed. This might be true in cities and out-of-town shopping areas but is rarely true in the UK for car parks in woods etc. Personally I disagree with the OSM requirement that footways from in/on the car park should be joined - this is just making up data that doesn't exist on the ground. When I've come across a footpath that goes into a car park but doesn't share a node or join correctly, I do try and fix them by both joining a ll the ways and by making them share nodes with the car park edge. Ticker

Hi Ticker, I'd prefer to remove the lines for the razed railways and the car parks. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 30. Juli 2020 13:56 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] default style lines enhancements Hi Gerd As the final arbiter, do you want styles/default/lines with: # Car parks often have multiple footway access; frequently these don't join up but are necessary to make # a continuous trail, so add a routable way that will be removed again if it doesn't join anything (parking=surface | (amenity=parking & parking!=*)) & access!=private & access!=no { set foot=yes; set vehicle=no; set mkgmap:numbers=false; set mkgmap:set_unconnected_type=none; set mkgmap:set_semi_connected_type=none; } [0x16 road_class=0 road_speed=0 resolution 23 continue] or commented out, maybe with more of an explanation. Ticker _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi all, I did some testing with the proposed changes in defaultStyleLines5.patch reg. car parks. There is one problem with the usage of set mkgmap:set_unconnected_type=none; set mkgmap:set_semi_connected_type=none; With the current code in mkgmap a ways that crosses the tile boundary is not changed by these rules, so these are likely to create routing islands. This was no problem as long as the above tags were meant to avoid adding service roads to the map but for the intended use in Tickers rules we would need a different logic. I see no way to calculate the wanted information without changes in splitter (a mixture of the --keep-complete and the --overlap strategy) and more logic in mkgmap to make sure that ways close to the tile boundary are not removed too early. So, probably too much work for a questionable use case like this. Alternative: Another special tag that tells mkgmap that the "routable way" (here the outline of the car park) should be removed when it crosses the tile boundary. I think it would be much better to use that time to fix the car parks where ways are not connected. I think I open a ticket for JOSM to ask for a validator test that flags a highway ending on amenity=parking area. I was surprised to find that this doesn't produce any message. I'll not have time to look at this in detail before September. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Greg Troxel <gdt@lexort.com> Gesendet: Donnerstag, 30. Juli 2020 15:08 An: Ticker Berkin Cc: mkgmap development Betreff: Re: [mkgmap-dev] default style lines enhancements Ticker Berkin <rwb-mkgmap@jagit.co.uk> writes:

I was only going to join up paths that share a node with the edge of the car park - I wasn't going to do anything with paths that just go near the edge.

I think that's irregular tagging, and not likely to be interpreted the way to intend by a number of routers, but I agree that this is a reasonable interpretation for mkgmap of that tagging when it occurs, which is the only thing that matters here.

I disagree with the assertion that there are always parking isles and if these don't exist in the OSM data for a car park it has not been mapped correctly and should be fixed. This might be true in cities and out-of-town shopping areas but is rarely true in the UK for car parks in woods etc.

I didn't mean there were always clear aisles. Just that you can usually/almost-always draw a way that goes into the area that more or less represents what you can do.

Personally I disagree with the OSM requirement that footways from in/on the car park should be joined - this is just making up data that doesn't exist on the ground.

The real issue is that the OSM tagging scheme is not rich enough to capture these nuances, and thus different people have different preferred ways to approximate reality given the tagging scheme that exists. Clearly a difference of opinion among reasonable people -- thanks for the discusision. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Mike, I don't understand that argument. If there is no existing way why should mkgmap generate one? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Freitag, 31. Juli 2020 09:38 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] default style lines enhancements Hi Gerd, the issue is not specific to car parks and will crop up with any use of mkgmap:set_unconnected_type. I believe it also affects checking of roundabouts and probably other things as well, so I don't see this as a reason for not including at least a commented version in the style. I do not agree that a highway ending at the edge of a car park is necessarily erroneous tagging, so it seems wrong to me to be suggesting that the problems should be 'fixed' in OSM by adding non-existent highways for routing purposes. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 31 July 2020 07:49 To: Ticker Berkin <rwb-mkgmap@jagit.co.uk>; Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] default style lines enhancements Hi all, I did some testing with the proposed changes in defaultStyleLines5.patch reg. car parks. There is one problem with the usage of set mkgmap:set_unconnected_type=none; set mkgmap:set_semi_connected_type=none; With the current code in mkgmap a ways that crosses the tile boundary is not changed by these rules, so these are likely to create routing islands. This was no problem as long as the above tags were meant to avoid adding service roads to the map but for the intended use in Tickers rules we would need a different logic. I see no way to calculate the wanted information without changes in splitter (a mixture of the --keep-complete and the --overlap strategy) and more logic in mkgmap to make sure that ways close to the tile boundary are not removed too early. So, probably too much work for a questionable use case like this. Alternative: Another special tag that tells mkgmap that the "routable way" (here the outline of the car park) should be removed when it crosses the tile boundary. I think it would be much better to use that time to fix the car parks where ways are not connected. I think I open a ticket for JOSM to ask for a validator test that flags a highway ending on amenity=parking area. I was surprised to find that this doesn't produce any message. I'll not have time to look at this in detail before September. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Greg Troxel <gdt@lexort.com> Gesendet: Donnerstag, 30. Juli 2020 15:08 An: Ticker Berkin Cc: mkgmap development Betreff: Re: [mkgmap-dev] default style lines enhancements Ticker Berkin <rwb-mkgmap@jagit.co.uk> writes:

I was only going to join up paths that share a node with the edge of the car park - I wasn't going to do anything with paths that just go near the edge.

I think that's irregular tagging, and not likely to be interpreted the way to intend by a number of routers, but I agree that this is a reasonable interpretation for mkgmap of that tagging when it occurs, which is the only thing that matters here.

I disagree with the assertion that there are always parking isles and if these don't exist in the OSM data for a car park it has not been mapped correctly and should be fixed. This might be true in cities and out-of-town shopping areas but is rarely true in the UK for car parks in woods etc.

I didn't mean there were always clear aisles. Just that you can usually/almost-always draw a way that goes into the area that more or less represents what you can do.

Personally I disagree with the OSM requirement that footways from in/on the car park should be joined - this is just making up data that doesn't exist on the ground.

The real issue is that the OSM tagging scheme is not rich enough to capture these nuances, and thus different people have different preferred ways to approximate reality given the tagging scheme that exists. Clearly a difference of opinion among reasonable people -- thanks for the discusision. _______________________________________________ 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