Re: [mkgmap-dev] change handling of railway=abandoned
Hi Greg, the previous rule existed since 2009 and I never liked it. It is not a special case in Garmin software but a workaround to fix improper tagging. I'd be happy to remove the new rule completely. If I got that right only Minko wants it. See again http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2016q3/025104.html Gerd Von: mkgmap-dev im Auftrag von Greg Troxel Gesendet: Dienstag, 21. Januar 2020 17:26 An: Ticker Berkin Cc: Development list for mkgmap Betreff: Re: [mkgmap-dev] change handling of railway=abandoned I think part of the problem is that railway=abandonded is not a statement either way about whether it is reasonably physically traversable on foot whether there is any right of access so I guess I don't see why a way with railway=abandonded and no highway tags should be presumed routable in the first place. I guess the real issue is that garmin thinks it is? (Also, for US people, note that OSM's definition of abandoned is different from the US definition. The US definition is a legal thing, and some rails that are US-abandoned have tracks present. Nothing to do in mkgmap, but if you are a US railfan and not an OSM expert, you'll assume wrong.) ___ 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] change handling of railway=abandoned
I think part of the problem is that railway=abandonded is not a statement either way about whether it is reasonably physically traversable on foot whether there is any right of access so I guess I don't see why a way with railway=abandonded and no highway tags should be presumed routable in the first place. I guess the real issue is that garmin thinks it is? (Also, for US people, note that OSM's definition of abandoned is different from the US definition. The US definition is a legal thing, and some rails that are US-abandoned have tracks present. Nothing to do in mkgmap, but if you are a US railfan and not an OSM expert, you'll assume wrong.) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit r4429: Default style: Use railway=abandoned only as routable way when certain criterias match
Version mkgmap-r4429 was committed by gerd on Tue, 21 Jan 2020 Default style: Use railway=abandoned only as routable way when certain criterias match http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4429 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] change handling of railway=abandoned
Just for the sake of argument: I don't like [access=no].
It's suggesting [access=no] is "default" access (which it's not).
Next step is to add the Exceptions: [bicycle=yes], [foot=yes].
Double denial, Conflicting information, Contradictio in terminis.
Also wondering: when is [access=no] - ever - correct?
Nuclear power plant? No: [access=private] (staff).
Nature Reserve (restricted access)? No: [access=private] (staff)/emergency.
Abandoned railway? No highway implies: "no access".
IMO: [railway=abandoned] is a property of (most typical) a cycleway,
indicating max 2% incline, straight way (dull, imo), often "cutting=yes"
(so: no view).
Also: not two ways (railway and highway), but one way only. Either railway
OR highway (+railway tag as property).
In the Netherlands this "sloppy mapping" (IMO) resulted in ERRORS after MANY
years.
1. [highway=footway]
2. [highway=path] (because without traffic_sign, SOME Mappers argue: this is
not a footway)
3. [highway=path] + [access=no] (because bicycle/moped/mofa now have default
access) + foot=yes (explicitly mapping the exception)
4. IMPROVED by UPDATE: [highway=footway] + [access=no] + [foot=yes]
5. DELETE [foot=yes] (because this is default access: "Needless tagging")
5. NOW on the MAP: [highway=footway] + [access=no]
This is an Error: to Resolve many Changesets have been Reverted by DWG in
which "foot = yes" was deleted ("Needless tagging") AND [foot=yes] was
ADDED.
Not only for [highway=footway] + [access=no] (tens of ways, at most) BUT for
ALL Reverted footways (thousands).
6. NOW on the MAP: [highway=footway] + [foot=yes] (thousands of footways in
the Netherlands)
7. JOSM now complains for EVERY Changeset Validation:
"unnecessary tag - foot=yes|designated is unnecessary for
highway=footway|pedestrian"
And I don't "dare" to delete….
Other example:
[highway=unclassified/track/path] + [access=no] + [foot=yes] + [bicycle=yes]
I would prefer: [highway=unclassified] + [motor_vehicle=no]
Long time ago I argued on a forum:
I buy bread in a bakery:
"One brown bread please."
"Here you are. Anything else?"
"No! Two croissants."
/ AnkEric
--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] change handling of railway=abandoned
Hi Ticker,
you are right, that's a good point.
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
Gesendet: Dienstag, 21. Januar 2020 13:18
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] change handling of railway=abandoned
Hi
The advantages of my rule is that it doesn't create a routable line if
there is no need for it and that it can become a footway or cycleway
depending on the tags.
Gerd's rule would create routable track then disable all access modes.
These are chosen as the start/end point of a route if closest and this
could be a problem.
Ticker
On Tue, 2020-01-21 at 11:34 +, Gerd Petermann wrote:
> Hi,
>
> @Bernhard:
> adding "access=no" doesn't make a way unroutable when the way has
> e.g. vehicle=yes or foot=yes. It just changes the default
> access which is assumed for highway=*. See also what happens in
> inc/access.
>
> Reg. Tickers Rule:
> I don't like it because it is more complex and somehow duplicates the
> code in inc/access.
>
> Reg. the missing highway!=* : Yes, that's needed. I forgot that we
> disabled the mop up rule for highway=*
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 21. Januar 2020 12:03
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] change handling of railway=abandoned
>
> Hi
>
> Gerd rule should be OK with the addition clause of & highway!=*, but
> is
> there any reason not to have what I suggested.
>
> Ticker
>
> On Tue, 2020-01-21 at 11:36 +0100, Bernhard Hiller wrote:
> > Hi Gerd,
> > of course, {deletealltags} is a different action: it removes the
> > way
> > completely. "{add access=no}" just makes it unroutable, but leaves
> > it
> > visible on the map.
> >
> > Lte's take a look at the roads in my example (due to changes during
> > the
> > last couple of hours, be sure to look at last year's version):
> > - the road to the south-west is a tertiary, without explicit access
> > tags, and railway=razed:
> > https://www.openstreetmap.org/way/326001702/history
> > - the road north-east into Meinershagen is a residential, without
> > explicit access tags, and railway=razed:
> > https://www.openstreetmap.org/way/617284819/history
> > - the road to the east is a primary, without explicit access tags,
> > and
> > railway=razed:
> > https://www.openstreetmap.org/way/306731105/history
> >
> > True, there is another difference: railway=razed is not
> > railway=abandoned. Can we be sure that all those tags used for
> > indicating a former railway, like abandoned - dismantled - disused
> > -
> > razed etc., are always used correctly? I tried an overpass api
> > search
> > for railway=abandoned and highway=*, but could not find out how to
> > do
> > it
> > correctly.
> >
> > If those roads had railway=abandoned instead, they would no more be
> > routable with your rule. Or is there some catch?
> >
> > Let's look at some examples showing that railway=abandoned is not
> > always
> > used so strictly (or are milestones next to the way enough hints
> > for
> > the
> > former presence of a railway?):
> > - https://www.openstreetmap.org/way/121395347 has
> > railway=abandoned,
> > highway=path, with explicit access tags for foot and bicycle. I
> > think
> > the rule won't cause trouble here.
> >
> > - https://www.openstreetmap.org/way/130369751 has
> > railway=abandoned,
> > path=cycleway, and an access tag for foot (but not for bicycle). I
> > think
> > the rule would then remove the access of bicycles to that cycleway.
> >
> > - https://www.openstreetmap.org/way/101937226 has not yet been
> > detected
> > by the historic railway mappers, and lacks any railway tags. The
> > rule
> > won't do anything here ;-)
> >
> > https://www.openstreetmap.org/way/561220394 has railway=abandoned,
> > path=cycleway, and access tags for foot and bicycle. The rule won't
> > cause trouble here.
> >
> > We should make sure that "access" won't be removed from highways
> > with
> > that rule.
> >
> > Kind regards,
> > Bernhard
> >
> >
> >
> > Am 20.01.2020 um 19:49 schrieb Gerd Petermann:
> > > Hi Bernhard,
> > >
> > > well, {add access=no} is very different to action {deletealltags}
> > > My thinking is that a railway=abandoned without highway=* still
> > > might be used as a highway if a tag like foot=yes or bicycle=yes
> > > exists.
> > > Tickers idea should have more or less the same effect.
> > >
> > > Gerd
> > >
> > >
> > > Von: Bernhard Hiller
> > > Gesendet: Montag, 20. Januar 2020 19:41
> > > An: Gerd Petermann
> > > Betreff: Re: [mkgmap-dev] change handling of railway=abandoned
> > >
> > > Hi Gerd,
> > > "add access=no" is a very dangerous option.
> > > In my style, I added a rule for removing such ways completely.
> > > And
> > > it
> > > failed terribly - today, there may be public roads on previous
> > > railways.
> > > See also my post in the forum at
> > > https://forum.openstreetmap.org/vie
Re: [mkgmap-dev] change handling of railway=abandoned
Hi
The advantages of my rule is that it doesn't create a routable line if
there is no need for it and that it can become a footway or cycleway
depending on the tags.
Gerd's rule would create routable track then disable all access modes.
These are chosen as the start/end point of a route if closest and this
could be a problem.
Ticker
On Tue, 2020-01-21 at 11:34 +, Gerd Petermann wrote:
> Hi,
>
> @Bernhard:
> adding "access=no" doesn't make a way unroutable when the way has
> e.g. vehicle=yes or foot=yes. It just changes the default
> access which is assumed for highway=*. See also what happens in
> inc/access.
>
> Reg. Tickers Rule:
> I don't like it because it is more complex and somehow duplicates the
> code in inc/access.
>
> Reg. the missing highway!=* : Yes, that's needed. I forgot that we
> disabled the mop up rule for highway=*
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 21. Januar 2020 12:03
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] change handling of railway=abandoned
>
> Hi
>
> Gerd rule should be OK with the addition clause of & highway!=*, but
> is
> there any reason not to have what I suggested.
>
> Ticker
>
> On Tue, 2020-01-21 at 11:36 +0100, Bernhard Hiller wrote:
> > Hi Gerd,
> > of course, {deletealltags} is a different action: it removes the
> > way
> > completely. "{add access=no}" just makes it unroutable, but leaves
> > it
> > visible on the map.
> >
> > Lte's take a look at the roads in my example (due to changes during
> > the
> > last couple of hours, be sure to look at last year's version):
> > - the road to the south-west is a tertiary, without explicit access
> > tags, and railway=razed:
> > https://www.openstreetmap.org/way/326001702/history
> > - the road north-east into Meinershagen is a residential, without
> > explicit access tags, and railway=razed:
> > https://www.openstreetmap.org/way/617284819/history
> > - the road to the east is a primary, without explicit access tags,
> > and
> > railway=razed:
> > https://www.openstreetmap.org/way/306731105/history
> >
> > True, there is another difference: railway=razed is not
> > railway=abandoned. Can we be sure that all those tags used for
> > indicating a former railway, like abandoned - dismantled - disused
> > -
> > razed etc., are always used correctly? I tried an overpass api
> > search
> > for railway=abandoned and highway=*, but could not find out how to
> > do
> > it
> > correctly.
> >
> > If those roads had railway=abandoned instead, they would no more be
> > routable with your rule. Or is there some catch?
> >
> > Let's look at some examples showing that railway=abandoned is not
> > always
> > used so strictly (or are milestones next to the way enough hints
> > for
> > the
> > former presence of a railway?):
> > - https://www.openstreetmap.org/way/121395347 has
> > railway=abandoned,
> > highway=path, with explicit access tags for foot and bicycle. I
> > think
> > the rule won't cause trouble here.
> >
> > - https://www.openstreetmap.org/way/130369751 has
> > railway=abandoned,
> > path=cycleway, and an access tag for foot (but not for bicycle). I
> > think
> > the rule would then remove the access of bicycles to that cycleway.
> >
> > - https://www.openstreetmap.org/way/101937226 has not yet been
> > detected
> > by the historic railway mappers, and lacks any railway tags. The
> > rule
> > won't do anything here ;-)
> >
> > https://www.openstreetmap.org/way/561220394 has railway=abandoned,
> > path=cycleway, and access tags for foot and bicycle. The rule won't
> > cause trouble here.
> >
> > We should make sure that "access" won't be removed from highways
> > with
> > that rule.
> >
> > Kind regards,
> > Bernhard
> >
> >
> >
> > Am 20.01.2020 um 19:49 schrieb Gerd Petermann:
> > > Hi Bernhard,
> > >
> > > well, {add access=no} is very different to action {deletealltags}
> > > My thinking is that a railway=abandoned without highway=* still
> > > might be used as a highway if a tag like foot=yes or bicycle=yes
> > > exists.
> > > Tickers idea should have more or less the same effect.
> > >
> > > Gerd
> > >
> > >
> > > Von: Bernhard Hiller
> > > Gesendet: Montag, 20. Januar 2020 19:41
> > > An: Gerd Petermann
> > > Betreff: Re: [mkgmap-dev] change handling of railway=abandoned
> > >
> > > Hi Gerd,
> > > "add access=no" is a very dangerous option.
> > > In my style, I added a rule for removing such ways completely.
> > > And
> > > it
> > > failed terribly - today, there may be public roads on previous
> > > railways.
> > > See also my post in the forum at
> > > https://forum.openstreetmap.org/viewtopic.php?id=66451
> > > Kind regards,
> > > Bernhard
> > >
> > > Am 18.01.2020 um 19:51 schrieb Gerd Petermann:
> > > > Hi all,
> > > >
> > > > the default style has this rule:
> > > > # following really should be removed, but see:
> > > > http://www.m
Re: [mkgmap-dev] change handling of railway=abandoned
Hi,
@Bernhard:
adding "access=no" doesn't make a way unroutable when the way has e.g.
vehicle=yes or foot=yes. It just changes the default
access which is assumed for highway=*. See also what happens in inc/access.
Reg. Tickers Rule:
I don't like it because it is more complex and somehow duplicates the code in
inc/access.
Reg. the missing highway!=* : Yes, that's needed. I forgot that we disabled the
mop up rule for highway=*
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
Gesendet: Dienstag, 21. Januar 2020 12:03
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] change handling of railway=abandoned
Hi
Gerd rule should be OK with the addition clause of & highway!=*, but is
there any reason not to have what I suggested.
Ticker
On Tue, 2020-01-21 at 11:36 +0100, Bernhard Hiller wrote:
> Hi Gerd,
> of course, {deletealltags} is a different action: it removes the way
> completely. "{add access=no}" just makes it unroutable, but leaves it
> visible on the map.
>
> Lte's take a look at the roads in my example (due to changes during
> the
> last couple of hours, be sure to look at last year's version):
> - the road to the south-west is a tertiary, without explicit access
> tags, and railway=razed:
> https://www.openstreetmap.org/way/326001702/history
> - the road north-east into Meinershagen is a residential, without
> explicit access tags, and railway=razed:
> https://www.openstreetmap.org/way/617284819/history
> - the road to the east is a primary, without explicit access tags,
> and
> railway=razed:
> https://www.openstreetmap.org/way/306731105/history
>
> True, there is another difference: railway=razed is not
> railway=abandoned. Can we be sure that all those tags used for
> indicating a former railway, like abandoned - dismantled - disused -
> razed etc., are always used correctly? I tried an overpass api search
> for railway=abandoned and highway=*, but could not find out how to do
> it
> correctly.
>
> If those roads had railway=abandoned instead, they would no more be
> routable with your rule. Or is there some catch?
>
> Let's look at some examples showing that railway=abandoned is not
> always
> used so strictly (or are milestones next to the way enough hints for
> the
> former presence of a railway?):
> - https://www.openstreetmap.org/way/121395347 has railway=abandoned,
> highway=path, with explicit access tags for foot and bicycle. I think
> the rule won't cause trouble here.
>
> - https://www.openstreetmap.org/way/130369751 has railway=abandoned,
> path=cycleway, and an access tag for foot (but not for bicycle). I
> think
> the rule would then remove the access of bicycles to that cycleway.
>
> - https://www.openstreetmap.org/way/101937226 has not yet been
> detected
> by the historic railway mappers, and lacks any railway tags. The rule
> won't do anything here ;-)
>
> https://www.openstreetmap.org/way/561220394 has railway=abandoned,
> path=cycleway, and access tags for foot and bicycle. The rule won't
> cause trouble here.
>
> We should make sure that "access" won't be removed from highways with
> that rule.
>
> Kind regards,
> Bernhard
>
>
>
> Am 20.01.2020 um 19:49 schrieb Gerd Petermann:
> > Hi Bernhard,
> >
> > well, {add access=no} is very different to action {deletealltags}
> > My thinking is that a railway=abandoned without highway=* still
> > might be used as a highway if a tag like foot=yes or bicycle=yes
> > exists.
> > Tickers idea should have more or less the same effect.
> >
> > Gerd
> >
> >
> > Von: Bernhard Hiller
> > Gesendet: Montag, 20. Januar 2020 19:41
> > An: Gerd Petermann
> > Betreff: Re: [mkgmap-dev] change handling of railway=abandoned
> >
> > Hi Gerd,
> > "add access=no" is a very dangerous option.
> > In my style, I added a rule for removing such ways completely. And
> > it
> > failed terribly - today, there may be public roads on previous
> > railways.
> > See also my post in the forum at
> > https://forum.openstreetmap.org/viewtopic.php?id=66451
> > Kind regards,
> > Bernhard
> >
> > Am 18.01.2020 um 19:51 schrieb Gerd Petermann:
> > > Hi all,
> > >
> > > the default style has this rule:
> > > # following really should be removed, but see:
> > > http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2016q3/025104.html
> > > railway«andoned [0x0a road_class=0 road_speed=1 resolution 22]
> > >
> > > I agree with Ticker that it is not a good idea to make such a way
> > > routable. I would accept this when it has also a tag like
> > > bicycle=s. I found a few ways like this, e.g.
> > > https://www.openstreetmap.org/way/122268824 (I wonder why nobody
> > > added a highway tag since 2011)
> > > BUT we should not assume access=s for a railway«andoned. So, what
> > > about this:
> > > railway«andoned {add access=no} [0x0a road_class=0 road_speed=1
> > > resolution 22]
> > >
> > > Gerd
> > >
>
> ___
> mkgmap-dev mailing list
> mkgmap-d
Re: [mkgmap-dev] change handling of railway=abandoned
Hi
Gerd rule should be OK with the addition clause of & highway!=*, but is
there any reason not to have what I suggested.
Ticker
On Tue, 2020-01-21 at 11:36 +0100, Bernhard Hiller wrote:
> Hi Gerd,
> of course, {deletealltags} is a different action: it removes the way
> completely. "{add access=no}" just makes it unroutable, but leaves it
> visible on the map.
>
> Lte's take a look at the roads in my example (due to changes during
> the
> last couple of hours, be sure to look at last year's version):
> - the road to the south-west is a tertiary, without explicit access
> tags, and railway=razed:
> https://www.openstreetmap.org/way/326001702/history
> - the road north-east into Meinershagen is a residential, without
> explicit access tags, and railway=razed:
> https://www.openstreetmap.org/way/617284819/history
> - the road to the east is a primary, without explicit access tags,
> and
> railway=razed:
> https://www.openstreetmap.org/way/306731105/history
>
> True, there is another difference: railway=razed is not
> railway=abandoned. Can we be sure that all those tags used for
> indicating a former railway, like abandoned - dismantled - disused -
> razed etc., are always used correctly? I tried an overpass api search
> for railway=abandoned and highway=*, but could not find out how to do
> it
> correctly.
>
> If those roads had railway=abandoned instead, they would no more be
> routable with your rule. Or is there some catch?
>
> Let's look at some examples showing that railway=abandoned is not
> always
> used so strictly (or are milestones next to the way enough hints for
> the
> former presence of a railway?):
> - https://www.openstreetmap.org/way/121395347 has railway=abandoned,
> highway=path, with explicit access tags for foot and bicycle. I think
> the rule won't cause trouble here.
>
> - https://www.openstreetmap.org/way/130369751 has railway=abandoned,
> path=cycleway, and an access tag for foot (but not for bicycle). I
> think
> the rule would then remove the access of bicycles to that cycleway.
>
> - https://www.openstreetmap.org/way/101937226 has not yet been
> detected
> by the historic railway mappers, and lacks any railway tags. The rule
> won't do anything here ;-)
>
> https://www.openstreetmap.org/way/561220394 has railway=abandoned,
> path=cycleway, and access tags for foot and bicycle. The rule won't
> cause trouble here.
>
> We should make sure that "access" won't be removed from highways with
> that rule.
>
> Kind regards,
> Bernhard
>
>
>
> Am 20.01.2020 um 19:49 schrieb Gerd Petermann:
> > Hi Bernhard,
> >
> > well, {add access=no} is very different to action {deletealltags}
> > My thinking is that a railway=abandoned without highway=* still
> > might be used as a highway if a tag like foot=yes or bicycle=yes
> > exists.
> > Tickers idea should have more or less the same effect.
> >
> > Gerd
> >
> >
> > Von: Bernhard Hiller
> > Gesendet: Montag, 20. Januar 2020 19:41
> > An: Gerd Petermann
> > Betreff: Re: [mkgmap-dev] change handling of railway=abandoned
> >
> > Hi Gerd,
> > "add access=no" is a very dangerous option.
> > In my style, I added a rule for removing such ways completely. And
> > it
> > failed terribly - today, there may be public roads on previous
> > railways.
> > See also my post in the forum at
> > https://forum.openstreetmap.org/viewtopic.php?id=66451
> > Kind regards,
> > Bernhard
> >
> > Am 18.01.2020 um 19:51 schrieb Gerd Petermann:
> > > Hi all,
> > >
> > > the default style has this rule:
> > > # following really should be removed, but see:
> > > http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2016q3/025104.html
> > > railway«andoned [0x0a road_class=0 road_speed=1 resolution 22]
> > >
> > > I agree with Ticker that it is not a good idea to make such a way
> > > routable. I would accept this when it has also a tag like
> > > bicycle=s. I found a few ways like this, e.g.
> > > https://www.openstreetmap.org/way/122268824 (I wonder why nobody
> > > added a highway tag since 2011)
> > > BUT we should not assume access=s for a railway«andoned. So, what
> > > about this:
> > > railway«andoned {add access=no} [0x0a road_class=0 road_speed=1
> > > resolution 22]
> > >
> > > 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
Re: [mkgmap-dev] mapnik TYP file changes
Hi Gerd >From experimenting with one of my Garmins (can't remember which one), if it couldn't find a label for the correct language, it just picked the first one in the label area for the object, regardless of the language. This seemed to be the first one textually in the file from the couple of cases I looked at. If the object doesn't have any TYP labels, then my eTrex HCx shows the in-build English label, but the eTrex 30x doesn't show anything. Ticker On Tue, 2020-01-21 at 10:23 +, Gerd Petermann wrote: > Hi Ticker, > > not sure if I like the idea of a default language using English. What > happens when the device is set to e.g. Turkish? Doesn't Garmin > provide a good default string for "Lake" in Turkish? > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Dienstag, 21. Januar 2020 10:31 > An: mkgmap development > Betreff: [mkgmap-dev] mapnik TYP file changes > > Hi all > > Patch attached that makes the following changes to mapnik.txt. This > is > held in resources/typ-files and distributed in examples/typ-files. > > - Add UTF-8 BOM at the start of the file, so that many text editors > and > mkgmap will recognise the encoding. > > - Add following line near start of file, for the same reasons: > ; -*- coding: UTF-8 -*- > > - comment out lines in the [_id] section; these are supplied / > overridden by mkgmap -- options > > - Change polygon 0x3d / "Bay" to be transparent, with a low > _drawOrder > > - Add a default language label string to every entry. This is used by > the Garmin device when there is no label for the language the device > is > set to. > > The basis on which I've set the default labels is roughly as follows: > > - Where my old Garmin device, without TYP file and for an unlabeled > object, gave a specific and unique label, used that. > > - For other cases, eg where the standard Garmin label is something > like > Road, Line, Area or Unnamed, used wording relevant to the OSM tags > that > are being mapped. > > - For some of the many Garmin Rivers and Lakes codes that we use for > other water areas, again used wording related to the OSM tag. > > - Where the English translation (language code 0x04) is close enough > to > the default label, I've deleted the English. I've also deleted the > English where I think the label (probably in all languages) doesn't > reflect the tag for which it is being used, but the default label > does. > > I've avoided making any changes to the visuals this TYP file produces > (apart from Bay), or to any language other than English. > > Ticker > ___ > 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] change handling of railway=abandoned
Hi Gerd,
of course, {deletealltags} is a different action: it removes the way
completely. "{add access=no}" just makes it unroutable, but leaves it
visible on the map.
Lte's take a look at the roads in my example (due to changes during the
last couple of hours, be sure to look at last year's version):
- the road to the south-west is a tertiary, without explicit access
tags, and railway=razed:
https://www.openstreetmap.org/way/326001702/history
- the road north-east into Meinershagen is a residential, without
explicit access tags, and railway=razed:
https://www.openstreetmap.org/way/617284819/history
- the road to the east is a primary, without explicit access tags, and
railway=razed:
https://www.openstreetmap.org/way/306731105/history
True, there is another difference: railway=razed is not
railway=abandoned. Can we be sure that all those tags used for
indicating a former railway, like abandoned - dismantled - disused -
razed etc., are always used correctly? I tried an overpass api search
for railway=abandoned and highway=*, but could not find out how to do it
correctly.
If those roads had railway=abandoned instead, they would no more be
routable with your rule. Or is there some catch?
Let's look at some examples showing that railway=abandoned is not always
used so strictly (or are milestones next to the way enough hints for the
former presence of a railway?):
- https://www.openstreetmap.org/way/121395347 has railway=abandoned,
highway=path, with explicit access tags for foot and bicycle. I think
the rule won't cause trouble here.
- https://www.openstreetmap.org/way/130369751 has railway=abandoned,
path=cycleway, and an access tag for foot (but not for bicycle). I think
the rule would then remove the access of bicycles to that cycleway.
- https://www.openstreetmap.org/way/101937226 has not yet been detected
by the historic railway mappers, and lacks any railway tags. The rule
won't do anything here ;-)
https://www.openstreetmap.org/way/561220394 has railway=abandoned,
path=cycleway, and access tags for foot and bicycle. The rule won't
cause trouble here.
We should make sure that "access" won't be removed from highways with
that rule.
Kind regards,
Bernhard
Am 20.01.2020 um 19:49 schrieb Gerd Petermann:
Hi Bernhard,
well, {add access=no} is very different to action {deletealltags}
My thinking is that a railway=abandoned without highway=* still might be used
as a highway if a tag like foot=yes or bicycle=yes exists.
Tickers idea should have more or less the same effect.
Gerd
Von: Bernhard Hiller
Gesendet: Montag, 20. Januar 2020 19:41
An: Gerd Petermann
Betreff: Re: [mkgmap-dev] change handling of railway=abandoned
Hi Gerd,
"add access=no" is a very dangerous option.
In my style, I added a rule for removing such ways completely. And it
failed terribly - today, there may be public roads on previous railways.
See also my post in the forum at
https://forum.openstreetmap.org/viewtopic.php?id=66451
Kind regards,
Bernhard
Am 18.01.2020 um 19:51 schrieb Gerd Petermann:
Hi all,
the default style has this rule:
# following really should be removed, but see:
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2016q3/025104.html
railway«andoned [0x0a road_class=0 road_speed=1 resolution 22]
I agree with Ticker that it is not a good idea to make such a way routable. I
would accept this when it has also a tag like bicycle=s. I found a few ways
like this, e.g. https://www.openstreetmap.org/way/122268824 (I wonder why
nobody added a highway tag since 2011)
BUT we should not assume access=s for a railway«andoned. So, what about this:
railway«andoned {add access=no} [0x0a road_class=0 road_speed=1 resolution 22]
Gerd
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mapnik TYP file changes
Hi Ticker, not sure if I like the idea of a default language using English. What happens when the device is set to e.g. Turkish? Doesn't Garmin provide a good default string for "Lake" in Turkish? Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Dienstag, 21. Januar 2020 10:31 An: mkgmap development Betreff: [mkgmap-dev] mapnik TYP file changes Hi all Patch attached that makes the following changes to mapnik.txt. This is held in resources/typ-files and distributed in examples/typ-files. - Add UTF-8 BOM at the start of the file, so that many text editors and mkgmap will recognise the encoding. - Add following line near start of file, for the same reasons: ; -*- coding: UTF-8 -*- - comment out lines in the [_id] section; these are supplied / overridden by mkgmap -- options - Change polygon 0x3d / "Bay" to be transparent, with a low _drawOrder - Add a default language label string to every entry. This is used by the Garmin device when there is no label for the language the device is set to. The basis on which I've set the default labels is roughly as follows: - Where my old Garmin device, without TYP file and for an unlabeled object, gave a specific and unique label, used that. - For other cases, eg where the standard Garmin label is something like Road, Line, Area or Unnamed, used wording relevant to the OSM tags that are being mapped. - For some of the many Garmin Rivers and Lakes codes that we use for other water areas, again used wording related to the OSM tag. - Where the English translation (language code 0x04) is close enough to the default label, I've deleted the English. I've also deleted the English where I think the label (probably in all languages) doesn't reflect the tag for which it is being used, but the default label does. I've avoided making any changes to the visuals this TYP file produces (apart from Bay), or to any language other than English. Ticker ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] mapnik TYP file changes
Hi all Patch attached that makes the following changes to mapnik.txt. This is held in resources/typ-files and distributed in examples/typ-files. - Add UTF-8 BOM at the start of the file, so that many text editors and mkgmap will recognise the encoding. - Add following line near start of file, for the same reasons: ; -*- coding: UTF-8 -*- - comment out lines in the [_id] section; these are supplied / overridden by mkgmap -- options - Change polygon 0x3d / "Bay" to be transparent, with a low _drawOrder - Add a default language label string to every entry. This is used by the Garmin device when there is no label for the language the device is set to. The basis on which I've set the default labels is roughly as follows: - Where my old Garmin device, without TYP file and for an unlabeled object, gave a specific and unique label, used that. - For other cases, eg where the standard Garmin label is something like Road, Line, Area or Unnamed, used wording relevant to the OSM tags that are being mapped. - For some of the many Garmin Rivers and Lakes codes that we use for other water areas, again used wording related to the OSM tag. - Where the English translation (language code 0x04) is close enough to the default label, I've deleted the English. I've also deleted the English where I think the label (probably in all languages) doesn't reflect the tag for which it is being used, but the default label does. I've avoided making any changes to the visuals this TYP file produces (apart from Bay), or to any language other than English. Ticker Index: resources/typ-files/mapnik.txt === --- resources/typ-files/mapnik.txt (revision 4428) +++ resources/typ-files/mapnik.txt (working copy) @@ -1,11 +1,5 @@ - -[_id] -ProductCode=1 -CodePage=65001 -[End] -[_comments] -;https://github.com/Jorisbo/Mkgmap-Mapnik-Style-Garmin -;jori...@hotmail.com +; TYP file to give mapnik rendering +; -*- coding: UTF-8 -*- NB: first 3 bytes/char in file is UTF-8 encoded ByteOrderMark (BOM) ; ;This program is free software; you can redistribute it and/or modify ;it under the terms of the GNU General Public License version 3 or @@ -16,14 +10,19 @@ ;MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU ;General Public License for more details. ; -;Auto generated: 20191209 18:13 -;From master: MKG -;As subset: mkgmap -;Based on mkgmap default style version: r4389 +;Author: jori...@hotmail.com ; +;Based on mkgmap default style version: r4293...4288 +; +[_id] +;ProductCode=1 set from --product-id +;FID=8094set from --family-id +;CodePage=65001 set from --code-page [End] +; [_drawOrder] Type=0x04b,1 +Type=0x03d,1 Type=0x002,2 Type=0x003,2 Type=0x007,2 @@ -45,7 +44,6 @@ Type=0x025,2 Type=0x026,2 Type=0x03b,2 -Type=0x03d,2 Type=0x046,2 Type=0x047,2 Type=0x048,2 @@ -77,12 +75,13 @@ Type=0x06c,8 Type=0x004,9 [End] +; [_polygon] type=0x02 ;GRMN_TYPE: Urban Areas/SMALL_CITY/Small urban area, less than 200 000 inhabitants/Non NT +String=Suburb String1=0x01,Résidentiel String2=0x02,Wohngebiet -String3=0x04,Residential String4=0x03,Bebouwing String7=0x15,Obszar mieszkalny String8=0x10,Residencial @@ -96,9 +95,9 @@ [_polygon] type=0x03 ;GRMN_TYPE: Urban Areas/TOWN/Urban area, less than 50 000 inhabitants/Non NT +String=Village String1=0x01,Résidentiel String2=0x02,Wohngebiet -String3=0x04,Residential String4=0x03,Bebouwing String7=0x15,Obszar mieszkalny String8=0x10,Residencial @@ -112,9 +111,9 @@ [_polygon] type=0x04 ;GRMN_TYPE: Large Manmade Areas/MILITARY_BASE/Military base area/Non NT +String=Military Base String1=0x01,Domaine militaire String2=0x02,Militärisches Sperrgebiet -String3=0x04,Military String4=0x03,Militair domein String7=0x15,Teren wojskowy String8=0x10,Militar @@ -162,9 +161,10 @@ [_polygon] type=0x05 ;GRMN_TYPE: Large Manmade Areas/PARKING_LOT/Parking lot area/Non NT +String=Parking Lot String1=0x01,Parking String2=0x02,Parkplatz -String3=0x04,Parking +String3=0x04,Car Park String4=0x03,Parkeerterrein String7=0x15,Parking String8=0x10,Estacionamento @@ -178,9 +178,10 @@ [_polygon] type=0x06 ;GRMN_TYPE: Large Manmade Areas/PARKING_GARAGE/Parking garage area/Non NT +String=Parking Garage String1=0x01,Garages String2=0x02,Garagen -String3=0x04,Garages +String3=0x04,Parking String4=0x03,Garages String7=0x15,Garaże String8=0x10,Garagem @@ -194,9 +195,9 @@ [_polygon] type=0x07 ;GRMN_TYPE: Large Manmade Areas/AIRPORT/Airport area/Non NT +String=Airport String1=0x01,Aéroport String2=0x02,Flughafen -String3=0x04,Airport String4=0x03,Vliegveld String7=0x15,Lotnisko String8=0x10,Aeroporto @@ -210,9 +211,9 @@ [_polygon] type=0x08 ;GRMN_TYPE: Large Manmade Areas/SHOPPING_AREA/Shopping area/Non NT +String=Shopping Center String1=0x01,Zone commerciale String2=0x02,Gewerbegebiet -String3=0x04,Commercial area String4=0x03,Commercieel gebied String7=0x15,Obszar handlowy String8=0x10,Área c
