[mkgmap-dev] default style lines enhancements

Fri Jul 31 09:52:33 BST 2020

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 at lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike at 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 at hotmail.com]
Sent: 31 July 2020 07:49
To: Ticker Berkin <rwb-mkgmap at jagit.co.uk>; Development list for mkgmap
<mkgmap-dev at 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 at lists.mkgmap.org.uk> im Auftrag von Greg
Troxel <gdt at 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 at 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 at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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