Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Hubert87]

I also regard

"cycleway:left=lane"
"cycleway:left:oneway=-1"

as the currently preferred method and have been mapping/tagging like 
this for a while now.


Just my two cents

Hubert87


Am 15.03.2019 um 00:12 schrieb althio:

Discussed: maybe there
https://lists.openstreetmap.org/pipermail/tagging/2018-May/036164.html
Decided : I don't know


Cmuelle introduces rather complex combinations of tags such as cycleway:left=lane + 
cycleway:left:oneway=-1, that should in his view be used instead of 
cycleway:left=opposite_lane.  Does anyone on this list know whether this change has been 
discussed anywhere, and where and when it has been decided that cycleway=opposite_lane is 
a "legacy tag" ? If so please point me at some references.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Multipolygon (several outers) forest with different leaf_types: mapping strategy?

[Martin Koppenhoefer]

sent from a phone

> On 14. Mar 2019, at 09:20, Markus  wrote:
> 
> Unlike a site or multipolygon relation, a
> group relation does *not* constitute a new object, but is merely the
> name of its members as a whole.


actually it does constitute an object, a group, and the fact that there is a 
proper name underlines this. It doesn’t need tags to describe its nature, as 
that is defined through the members.


Cheers, Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging disputed boundaries

[Yuri Astrakhan]

On Thu, Mar 14, 2019 at 7:24 PM Phake Nick  wrote:

> Come to think of it, if the goal is to represent different perspective of
> disputed territory, then mapping disputed territories as disputed territory
> using claimed_by=* controlled_by=* does not seems like a good idea, as such
> an area in OSM would need to include a line separating the disputed
> territory from the territory it control which a number of countries would
> refuse to recognize. I think it's better to simply map the outer boundary
> of those countries' theoretical border and apply relevant tags describing
> the identify of the area instead.
>

Agree, a separate relation that outlines a country's border from that
country's perspective would be much easier to use (with an appropriate tag
- e.g. POV=countrycode).  Note that this also applies to sub-country admin
levels too, e.g. Crimea might have a different administrative division
according to UK and RU, which in some cases would be the same as
on-the-ground-truth.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging disputed boundaries

[Phake Nick]

Come to think of it, if the goal is to represent different perspective of
disputed territory, then mapping disputed territories as disputed territory
using claimed_by=* controlled_by=* does not seems like a good idea, as such
an area in OSM would need to include a line separating the disputed
territory from the territory it control which a number of countries would
refuse to recognize. I think it's better to simply map the outer boundary
of those countries' theoretical border and apply relevant tags describing
the identify of the area instead.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - police=*

[althio]

Martin Koppenhoefer  wrote:
> > If this seems viable, I would expand the proposal by a migration proposal 
> > from amenity=police to police=station
>
> I don’t think we should abandon amenity=police and it will likely not happen 
> unless people tag so many different things with the tag that it becomes 
> useless. My primary interest is in specifying the kind of police and 
> facility, a generic amenity=police on top of that does not harm. If the new 
> scheme becomes so widespread that every police station also has a more 
> specific police=* tag, we can still decide to remove the amenity=police tags.

+1
amenity=police + police=* is a established way of refining the tagging.
There is no need to abandon amenity=police for public facing police stations.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Phake Nick]

I mean, these route variants can probably be remapped as superroute if
superroute become more popular

2019年3月15日 06:34 於 "marc marc"  寫道：

a route_master isn't a superroute, isn't it ?
it's a collection off all variant of a "single" route
  and not several part of one route like superroute for E-network

route_master are well documented/used for bus route
but if someone want to convert a single type=route into a superroute (so
a type=route having relation as member), imho it's better to make a
propal with a good doc to allow app to add this case.
if not, currently valid route 'll become unusable in all app.
so sure that's the best/most need thing todo with PT version :(

Le 14.03.19 à 23:25, Phake Nick a écrit :

> It really depends on exactly how complex the route is, something like
> https://www.openstreetmap.org/relation/4776035 this bus route can
> definitely use it. (and I haven't mentioned other similar bus routes
> with different numbers in different relationship yet)
>
> 在 2019年3月15日週五 03:31，Paul Allen  > 寫道：

>
> On Thu, 14 Mar 2019 at 19:23, Peter Elderson  > wrote:
>
> Op do 14 mrt. 2019 om 18:17 schreef Paul Allen
> mailto:pla16...@gmail.com>>:

>
> On Thu, 14 Mar 2019 at 15:09, Jo  > wrote:
>
> I would definitely want routes to be composed of
> subroutes which are shared with other routes,
>
>
> I see that as less than useful for any route I know of.
>
>
> It's useful for longer routes through walking/cycling node
> networks, using the network signposting.
>
>
> Yeah, I can see it would be.  And for longer bus routes.  Just not
> for any of the bus routes I know
> around here and am likely to map.  You end up with the only common
> segments being very short
> around a central bus station, then they all diverge.  Once diverged,
> there is nothing to share.
>
> I'm not against such sharing in principle, where it makes sense.
> But if it comes at the price
> that all bus stops have to be in the aggregate relation and not in
> the subroutes then it becomes
> useless for my purposes.  And I freely admit that my purposes are a
> fairly rare case, but I'd
> still like to handle it.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/tagging

>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Warin]

On 15/03/19 04:39, Paul Allen wrote:
On Thu, 14 Mar 2019 at 16:44, Martin Koppenhoefer 
mailto:dieterdre...@gmail.com>> wrote:



> On 14. Mar 2019, at 16:49, Tony Shield mailto:tony.shield...@gmail.com>> wrote:
>
> Can they currently be edited with JOSM?


of course, you simply add a relation as member to another relation.


Can you?  It's not clear to me from the documentation that I can do 
that in a way that achieves what
I want to do and is compatible with accepted usage.  If you can tell 
me how to do that I'll be very

happy.

Let me be clear.  I want to decompose a route into segments and then 
construct some sort of
relation (ordinary, superroute or whatever) that assembles them in 
sequence.


Take a look at some that already exist.
Super relation 176684 in
https://hiking.waymarkedtrails.org/#route?id=176684=5!-27.1268!148.8261
You can see it is composed of 4 relations. Using the elevation profile 
you can follow the route from south to north so they are in sequence 
(there are a few out of order bits within the sub relations .. grr) and 
it finishes up with the alternative routes (very incomplete) that are a 
bit random along the length.  So it is possible to organise them into a 
sequence.



I want to do this
because I have a route which traverses some ways twice.  I want to do 
this because the same route
has ways which are traversed twice (A, B, C, D) but the first time the 
stop at C is ignored (you can
neither board nor alight there) and the second time the stop at C is 
usable (you can board or alight).
I want to do this because although the route is circular, it is 
"hairy" (in the mathematical sense), it's
not an "O" but an "O=".  The same way is traversed twice in opposite 
directions: in a non-circular
route that would be two variants of a route master but this is a 
circular route.


Being able to decompose the route solves several problems.  As a 
single route it is a real pain
to edit because the tools don't fully support the same way appearing 
twice (maybe there's a JOSM
plugin that does it better).  I still have a gap on the route 
according to JOSM validator but I
can't spot it.  It doesn't show as a red dot in the edit relation 
table, I can't see it by scrolling through
the list of ways and looking at them, when I go to the validator and 
try zooming to the problem
nothing happens.  It's in one of the ways that gets traversed twice 
and it's driving me crazy.  I think
that subroutes would make it a lot easier for me to zero in on the 
problem.


Route with the same way twice? These 2 have the same ways twice - in 
different directions

relation 3550083
relation 7258397

Both edited in JOSM - so it is possible to add the same way twice .. it 
does give a warning pop up that you click through.
That pop up has an option to permanently deny entering things twice... 
oh and are you in expert mode?





As a single route it's impossible to figure out by simple inspection 
of the query tool:

https://www.openstreetmap.org/relation/8592409#map=14/52.0860/-4.6644
You tell me where it goes in what sequence without delving deeply into 
the relation.  I'll give
you a hint: it starts and ends here: 
https://www.openstreetmap.org/node/3642998002
Want another hint?  It doesn't just start and end there, it also stops 
there in the middle of its
route.  Without looking at the details of the relation, tell me where 
it goes next after that
starting point.  Being able to decompose it into segments would allow 
people to see a
sequence of segments in order (such as via umap) and it would be 
obvious what the route
is.  Having segments would allow me to deal with the stop that is 
passed twice (in the same
direction) but is only used once - it would appear on one segment but 
not the other.


I don't see the query tool as being appropriate for routes. What you 
would probably like is something like the waymarked trails but for 
public transport... ???


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Status of oneway=cw oneway=ccw

[Hufkratzer]

  It is indeed interesting to store that the signs work only for one 
direction,

therefore oneway=yes/no is documented for hiking routes
- in https://wiki.openstreetmap.org/wiki/Hiking#Tags_of_the_relation 
since Jan. 2013
- in 
https://wiki.openstreetmap.org/wiki/Tag:route=hiking#Tags_of_the_relation since 
Mar. 2016

and we already have 1.2k relations with oneway=yes
and zero with oneway=signed, bidirectional=no or signed_oneway=yes.

On 14.03.2019 21:31, Volker Schmidt wrote:
> I second Martin. No "oneway" key in this case.
> On Thu, 14 Mar 2019 at 21:18, Martin Koppenhoefer 
 wrote:

>
>
>
> sent from a phone
>
> > On 14. Mar 2019, at 11:43, Sarah Hoffmann  wrote:
> >
> > or oneway=signed if you think it clashes with the legal
> > restriction tags).
>
>
> or bidirectional=no
> or signed_oneway=yes
>
> it shouldn’t be a value of the “oneway” key, there’s nothing 
preventing you from doing the route in the counterdirection, especially 
if you are with a map from OpenStreetMap ;-)

>
> Yes, it could be interesting to store that the signs work only 
for one direction, but this is very different from a oneway.

>
>
> Cheers, Martin

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk] Tagging disputed boundaries

[Paul Allen]

On Thu, 14 Mar 2019 at 22:58, Martin Koppenhoefer 
wrote:

> There are indications that at least 2 other secret groups operating in osm
> are suspicious about the plans for a new group and are planning to covf
>

+1
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Paul Allen]

On Thu, 14 Mar 2019 at 22:34, marc marc  wrote:

> a route_master isn't a superroute, isn't it ?
> it's a collection off all variant of a "single" route
>   and not several part of one route like superroute for E-network
>

That's how I understand it.  But I may be wrong.

>
> route_master are well documented/used for bus route
> but if someone want to convert a single type=route into a superroute (so
> a type=route having relation as member), imho it's better to make a
> propal with a good doc to allow app to add this case.
>

Erm, why?  The documentation for superroute, such as it is, says that one
reason is to map
things like the E-network and the other reason is to avoid a route with
more than 300 elements.
Obviously, if you had a route with 301 elements you would be entitled to
divide it and end up
with two subroutes of around 150 elements.  Or a subroute with 295 elements
and a
subroute with 6elements if that led to a more "natural" division.  But that
300 isn't a hard number,
as I understand it, and it would be OK to split for 290, or 280.

I'd just like to use it on a route with even fewer elements and I don't see
anything in the
documentation to say I can't.  If routers can handle a superroute for the
E-network they can
handle it for smaller routes.


> if not, currently valid route 'll become unusable in all app.
> so sure that's the best/most need thing todo with PT version :(
>

Again, if superroutes don't work with some apps the E-network has problems
and we either
have to abolish superroutes completely or fix broken apps or live with the
fact that some apps
are broken.

Since the route I'm talking about doesn't connect two transport nexuses,
broken routeing isn't
as big an issue for me as for the E-network.  Much more important is that
any tourist or visitor
(or even locals who rarely use the bus and haven't used this one since it
came into service a few
months ago) wanting to use the bus can figure out where it goes.  That
isn't easy.  Not even
if you have the timetable
https://www.richardsbros.co.uk/wp-content/uploads/2018/08/408-sept-2018.pdf
and know the local geography well.

At the risk of people getting deja vu all over again (thanks, Yogi Berra) I
invite you to try to figure
out this bus route:
https://www.openstreetmap.org/relation/8592409#map=14/52.0860/-4.6644
You'd have to either open it in an editor (if you're a registered user) or
work your way down the
ways listed in the relation, opening each in a new tab or window (or you
could just click on it
and then use the browser's back button but that's slower).

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk] Tagging disputed boundaries

[Martin Koppenhoefer]

There are indications that at least 2 other secret groups operating in osm are 
suspicious about the plans for a new group and are planning to covf
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Martin Koppenhoefer]

sent from a phone

> On 14. Mar 2019, at 23:13, Antoine Riche via Tagging 
>  wrote:
> 
> Cmuelle introduces rather complex combinations of tags such as 
> cycleway:left=lane + cycleway:left:oneway=-1, that should in his view be used 
> instead of cycleway:left=opposite_lane.  Does anyone on this list know 
> whether this change has been discussed anywhere,


I don’t know if this was recently discussed somewhere, but for me the „new“ 
tagging is self explanatory while I always struggled with the implications of 
„opposite_lane“


Cheers, Martin ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping deforestation wikipage

[Warin]

On 14/03/19 06:49, Lorenzo Stucchi wrote:

Hi all,

After some discussion about the idea of this project, we think to 
better capt all the idea to create a wiki page with the purpose of 
better understand the problem and find the better way to tag this 
situation.


So we create a wiki page 
https://wiki.openstreetmap.org/wiki/PoliMappers/mapping_deforestation where 
is possible to discuss these thematics, let us known your idea.




I think what your trying to map is the reduction of trees over time 
(deforestation).


Open Historic Map is the place to map what has happened over time. Here 
you can map the presence of trees at a particular point in time from 
satellite imagery at that time. This can give you the 'deforestation' 
information without trying to map 'here is a lack of trees'.




Open Street Map is the present, not the past. So OSM is not the place to 
map the change in tree cover.While some may be happy with mapping an 
area with a tag that says 'here is a lack of trees', that lack of trees 
does not tell you that the area was covered by trees at some time in the 
past. An example would be an area coved by rock, an old village area. I 
think what you are after is that change in tree cover, and that is not 
mapped in OSM.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping deforestation wikipage

[Graeme Fitzpatrick]

On Fri, 15 Mar 2019 at 07:30, Tod Fitch  wrote:

>
> > On Mar 14, 2019, at 2:04 PM, Kevin Kenny 
> wrote:
> >
>
> > I just saw two replies to Lorenzo that were suggesting that his source
> > data were unmappable because they didn't support a sufficiently
> > detailed taxonomy of landcover, and I wanted to point out that "no
> > trees here" is useful information that should be distinguished from
> > "we haven't yet looked to see if there are trees here."
> >
> > "was:landcover=trees" is not something that I favour, because there's
> > also the useful combination, "no trees in the old imagery, and no
> > trees in the current imagery either", still without information about
> > whether one is looking at grass, scrub, heath, meadow, wetland or
> > farmland, which can't always be distinguished in orthoimages.  I
> > suppose that the "no:landcover=trees" COULD work, but I don't see
> > no:*=* in wide use, and suspect that it will be controversial.
> >
>
> Why not landcover=vegetation as an equivalent to highway=road? It would
> indicate that some type of plant matter is growing on it but exactly what
> is not yet known. Once more information (field survey? low level aerial
> survey/photos?) is available then a more specific landcover could be
> applied.
>

Or for an even more general "I don't know what I'm looking at"!

landcover=undetermined / unknown?

"That particular area is covered by trees, that area over there has
buildings on it, but when I looked at this area, on this day, I couldn't
work out what the landcovering was, so someone will have to check it again"

Thanks

Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[marc marc]

a route_master isn't a superroute, isn't it ?
it's a collection off all variant of a "single" route
  and not several part of one route like superroute for E-network

route_master are well documented/used for bus route
but if someone want to convert a single type=route into a superroute (so 
a type=route having relation as member), imho it's better to make a 
propal with a good doc to allow app to add this case.
if not, currently valid route 'll become unusable in all app.
so sure that's the best/most need thing todo with PT version :(

Le 14.03.19 à 23:25, Phake Nick a écrit :
> It really depends on exactly how complex the route is, something like 
> https://www.openstreetmap.org/relation/4776035 this bus route can 
> definitely use it. (and I haven't mentioned other similar bus routes 
> with different numbers in different relationship yet)
> 
> 在 2019年3月15日週五 03:31，Paul Allen  > 寫道：
> 
> On Thu, 14 Mar 2019 at 19:23, Peter Elderson  > wrote:
> 
> Op do 14 mrt. 2019 om 18:17 schreef Paul Allen
> mailto:pla16...@gmail.com>>:
> 
> On Thu, 14 Mar 2019 at 15:09, Jo  > wrote:
> 
> I would definitely want routes to be composed of
> subroutes which are shared with other routes,
> 
> 
> I see that as less than useful for any route I know of. 
> 
> 
> It's useful for longer routes through walking/cycling node
> networks, using the network signposting.
> 
> 
> Yeah, I can see it would be.  And for longer bus routes.  Just not
> for any of the bus routes I know
> around here and am likely to map.  You end up with the only common
> segments being very short
> around a central bus station, then they all diverge.  Once diverged,
> there is nothing to share.
> 
> I'm not against such sharing in principle, where it makes sense. 
> But if it comes at the price
> that all bus stops have to be in the aggregate relation and not in
> the subroutes then it becomes
> useless for my purposes.  And I freely admit that my purposes are a
> fairly rare case, but I'd
> still like to handle it.
> 
> -- 
> Paul
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/tagging
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Phake Nick]

It really depends on exactly how complex the route is, something like
https://www.openstreetmap.org/relation/4776035 this bus route can
definitely use it. (and I haven't mentioned other similar bus routes with
different numbers in different relationship yet)

在 2019年3月15日週五 03:31，Paul Allen  寫道：

> On Thu, 14 Mar 2019 at 19:23, Peter Elderson  wrote:
>
>> Op do 14 mrt. 2019 om 18:17 schreef Paul Allen :
>>
>>> On Thu, 14 Mar 2019 at 15:09, Jo  wrote:
>>>
 I would definitely want routes to be composed of subroutes which are
 shared with other routes,

>>>
>>> I see that as less than useful for any route I know of.
>>>
>>
>> It's useful for longer routes through walking/cycling node networks,
>> using the network signposting.
>>
>
> Yeah, I can see it would be.  And for longer bus routes.  Just not for any
> of the bus routes I know
> around here and am likely to map.  You end up with the only common
> segments being very short
> around a central bus station, then they all diverge.  Once diverged, there
> is nothing to share.
>
> I'm not against such sharing in principle, where it makes sense.  But if
> it comes at the price
> that all bus stops have to be in the aggregate relation and not in the
> subroutes then it becomes
> useless for my purposes.  And I freely admit that my purposes are a fairly
> rare case, but I'd
> still like to handle it.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Expand the key:opening_hours

[Phake Nick]

在 2019年3月14日週四 20:38，Simon Poole  寫道：

> Some more comments:
>
> - the OH values are currently always evaluated in the local time zone
> (or to go even a bit further in a local context as the location they
> apply to is always known), so a time zone indicator would be only needed
> in the cases that require different processing, the question is if that
> is common enough to justify the additional complication.
>
The three most prominent area that are still using the calendar nowadays
are China, Korea, Vietnam. Each of them have their own version of this
lunar calendar with the most notable difference being the meridian used to
create the calendar. So that once in a few years you could see reports
saying that the lunar calendar and the festival that depends on it are not
correct on some software.

Let's say you represent the Lunar New Year as L01 01. The software can
assume it mean Chinese New Year in China, Vietnamese New Year in Vietnam,
and Korean New Year in Korea. So far so good. But then these festivals
aren't just celebrated within these three countries. Places like Thailand,
Indonesia, Japan, Australia, America, and many other countries around the
world all have different events that would take place for the Lunar New
Year. Sometimes they're commercial events that are currently catering
specifically to Chinese New Year. Sometimes they are diaspora population
that celebrate the festival on the same day as their parent countries. You
cannot know which exact day it's referring to without referring to the
timezone being used to calculate the calendar, and at least it need to
specify Korean/Chinese/Vietnamese version and that is assuming the region
will not create any new timezone in the future, like how time changes
related to the Vietnamese war caused the North Vietnam and South Vietnam
celebrated the new year at different date back then and resulted in some
military advantages.

One might think it'd be easier to add CNY/KNY/VNY into the variable holiday
separately like easter instead, but there are a number of other events
that're celebrated based on local lunar calendar and is celebrated at more
places than those aforementioned countries, like Confucius birthday,
mid-autumn festival, double nine festival, and so on. If calendar-specific
version of all these holidays are all getting their own values as
variable-holiday then there would be too many of them.

And there also other scenario that timezone value is useful, for instance
iirc Fiji decided that the country will implement DST but the school system
operation time will not follow the transition. Or in places like Xinjiang
or West Bank where there are two different timezones used by different
population living in same area.


> - Summer and winter solstice can be, as far as I can see, modelled as
> additional variable_date values (currently only "easter" is defined), I
> would avoid qualifying them with months as again, that require parser
> changes that will cause issues.
>

Except other solar terms are still used. For example March equinox and
September equinox are national holiday in Japan. Setsubun celebration in
Japan is mainly a day before first solar term in February but also a day
before first solar term in May, August, November. Qing Ming (mainly China,
Korea, etc.) is the first solar term in April.

>

> - Lunar months: are there any common names for these instead of just
> numbering? And how are the "leap" variants supposed to be different?
>
> Simon
>

It is usually just numbering, but in Chinese there are nickname for the
11th and 12th month, while in Japanese there are nickname for all the
months. Consider that those nick name are less popular, regional-specific
and language-specific, it seems like it would be a bad idea to name them
after the months.
The "leap" version are for when a year have 13 lunar months. Instead of
naming the additional month the 13th month, various criteria are used to
select one of those thirteen months, and then name it as the "leap" version
of the previous month. There are on average about 7 years with leap month
in every 19 years.

>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Antoine Riche via Tagging]

Hello.
(message resent without annoying formatting, apologies)

Yesterday Wiki user Cmuelle8 
(https://wiki.openstreetmap.org/wiki/User:Cmuelle8) changed a number of 
Wiki pages with the following comment :(opposite_lane is a value for 
unaffixed legacy cycleway=* tags (!!), it has no meaning with 
cycleway:left, cycleway:right and cycleway:both and must not be used in 
combination; use *:oneway=* which is indpendent of left/right hand 
traffic systems)


The pages affected are 
https://wiki.openstreetmap.org/wiki/Key%3Acycleway and 
https://wiki.openstreetmap.org/wiki/Bicycle, as well as the french 
version of the former. There might be others.


Cmuelle introduces rather complex combinations of tags such as 
cycleway:left=lane + cycleway:left:oneway=-1, that should in his view be 
used instead of cycleway:left=opposite_lane. 
 Does anyone on 
this list know whether this change has been discussed anywhere, and 
where and when it has been decided that cycleway=opposite_lane is a 
"legacy tag" ? If so please point me at some references.


I cannot find any recent discussion about this and am wondering whether 
this wiki change is an attempt to force a change in the model with no 
discussion with the community...


Antoine.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

[Antoine Riche via Tagging]

Hello.

Yesterday Wiki user Cmuelle8 
(https://wiki.openstreetmap.org/wiki/User:Cmuelle8) changed a number of 
Wiki pages with the following comment :(opposite_lane is a value for 
unaffixed legacy cycleway=* tags (!!), it has no meaning with 
cycleway:left, cycleway:right and cycleway:both and must not be used in 
combination; use *:oneway=* which is indpendent of left/right hand 
traffic systems)


The pages affected are 
https://wiki.openstreetmap.org/wiki/Key%3Acycleway and 
https://wiki.openstreetmap.org/wiki/Bicycle, as well as the french 
version of the former. There might be others.


Cmuelle introduces rather complex combinations of tags such as 
cycleway:left 
=lane 
 + 
cycleway :left 
:oneway 
=-1 
. that should in 
his view be used instead of cycleway:left=opposite_lane. 
 Does anyone on 
this list know whether this change has been discussed anywhere, and 
where and when it has been decided that cycleway=opposite_lane is a 
"legacy tag" ? If so please point me at some references.


I cannot find any recent discussion about this and am wondering whether 
this wiki change is an attempt to force a change in the model with no 
discussion with the community...


Antoine.


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - police=*

[Martin Koppenhoefer]

sent from a phone

> On 14. Mar 2019, at 20:17, Jan S  wrote:
> 
> If this seems viable, I would expand the proposal by a migration proposal 
> from amenity=police to police=station


I don’t think we should abandon amenity=police and it will likely not happen 
unless people tag so many different things with the tag that it becomes 
useless. My primary interest is in specifying the kind of police and facility, 
a generic amenity=police on top of that does not harm. If the new scheme 
becomes so widespread that every police station also has a more specific 
police=* tag, we can still decide to remove the amenity=police tags.

Cheers, Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping deforestation wikipage

[marc marc]

adding top-level categories to the landcover value is maybe
the best idea, it allow incremential mapping :
- you 'll add true value depending of your "level" and the quality
of the source
- another day another mapper may improve it.

Le 14.03.19 à 22:33, Lorenzo Stucchi a écrit :
> Hi all,
> 
> sorry I change the idea from just landcover to sat_landcover because I 
> saw it as reasonable for a draft landcover in an area for which I don’t 
> know exactly if what I’m mapping is a meadow or a cultivated land or 
> something similar, but I understand in which of the categories it fall, 
> as we explain into the wiki page.
> 
> So if you think that it's better to return back to just landcover for me 
> it’s fine.
> 
> We just want to point the problem and the importance of a theme like 
> deforestation in a big forest and his effect on climate change. But if 
> there are no data about how is possible to do that?
> 
> So from this reason, we have this proposal after reading pages of the 
> wiki trying to find the best solution to tag these elements. We don’t 
> want to create anything that can be forgotten after our event instead, 
> we think that this can be an important issue that can be taken care of 
> part of OSM community.
> 
> Any help is welcome and please try to remain focus on the starting point 
> and not diverge like in the previous thread. Sorry we care very much on 
> this project and we believe in the his importance.
> 
> Thanks Tod for this point this is what we are exactly talking about.
> 
> Best,
> Lorenzo
> 
>> Il giorno 14 mar 2019, alle ore 22:29, Tod Fitch > > ha scritto:
>>
>>>
>>> On Mar 14, 2019, at 2:04 PM, Kevin Kenny >> > wrote:
>>>
>>> On Thu, Mar 14, 2019 at 4:51 PM marc marc >> > wrote:
 no:landcover=trees ?
 or, as the previous landcover/imagery show tress, was:landcover=trees
>>>
>>> However you want to spell it.
>>>
>>> I just saw two replies to Lorenzo that were suggesting that his source
>>> data were unmappable because they didn't support a sufficiently
>>> detailed taxonomy of landcover, and I wanted to point out that "no
>>> trees here" is useful information that should be distinguished from
>>> "we haven't yet looked to see if there are trees here."
>>>
>>> "was:landcover=trees" is not something that I favour, because there's
>>> also the useful combination, "no trees in the old imagery, and no
>>> trees in the current imagery either", still without information about
>>> whether one is looking at grass, scrub, heath, meadow, wetland or
>>> farmland, which can't always be distinguished in orthoimages.  I
>>> suppose that the "no:landcover=trees" COULD work, but I don't see
>>> no:*=* in wide use, and suspect that it will be controversial.
>>>
>>
>> Why not landcover=vegetation as an equivalent to highway=road? It 
>> would indicate that some type of plant matter is growing on it but 
>> exactly what is not yet known. Once more information (field survey? 
>> low level aerial survey/photos?) is available then a more specific 
>> landcover could be applied.
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/tagging
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping deforestation wikipage

[Lorenzo Stucchi]

Hi all,

sorry I change the idea from just landcover to sat_landcover because I saw it 
as reasonable for a draft landcover in an area for which I don’t know exactly 
if what I’m mapping is a meadow or a cultivated land or something similar, but 
I understand in which of the categories it fall, as we explain into the wiki 
page.

So if you think that it's better to return back to just landcover for me it’s 
fine.

We just want to point the problem and the importance of a theme like 
deforestation in a big forest and his effect on climate change. But if there 
are no data about how is possible to do that?

So from this reason, we have this proposal after reading pages of the wiki 
trying to find the best solution to tag these elements. We don’t want to create 
anything that can be forgotten after our event instead, we think that this can 
be an important issue that can be taken care of part of OSM community.

Any help is welcome and please try to remain focus on the starting point and 
not diverge like in the previous thread. Sorry we care very much on this 
project and we believe in the his importance.

Thanks Tod for this point this is what we are exactly talking about.

Best,
Lorenzo

Il giorno 14 mar 2019, alle ore 22:29, Tod Fitch 
mailto:t...@fitchdesign.com>> ha scritto:


On Mar 14, 2019, at 2:04 PM, Kevin Kenny 
mailto:kevin.b.ke...@gmail.com>> wrote:

On Thu, Mar 14, 2019 at 4:51 PM marc marc 
mailto:marc_marc_...@hotmail.com>> wrote:
no:landcover=trees ?
or, as the previous landcover/imagery show tress, was:landcover=trees

However you want to spell it.

I just saw two replies to Lorenzo that were suggesting that his source
data were unmappable because they didn't support a sufficiently
detailed taxonomy of landcover, and I wanted to point out that "no
trees here" is useful information that should be distinguished from
"we haven't yet looked to see if there are trees here."

"was:landcover=trees" is not something that I favour, because there's
also the useful combination, "no trees in the old imagery, and no
trees in the current imagery either", still without information about
whether one is looking at grass, scrub, heath, meadow, wetland or
farmland, which can't always be distinguished in orthoimages.  I
suppose that the "no:landcover=trees" COULD work, but I don't see
no:*=* in wide use, and suspect that it will be controversial.


Why not landcover=vegetation as an equivalent to highway=road? It would 
indicate that some type of plant matter is growing on it but exactly what is 
not yet known. Once more information (field survey? low level aerial 
survey/photos?) is available then a more specific landcover could be applied.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping deforestation wikipage

[Tod Fitch]

> On Mar 14, 2019, at 2:04 PM, Kevin Kenny  wrote:
> 
> On Thu, Mar 14, 2019 at 4:51 PM marc marc  wrote:
>> no:landcover=trees ?
>> or, as the previous landcover/imagery show tress, was:landcover=trees
> 
> However you want to spell it.
> 
> I just saw two replies to Lorenzo that were suggesting that his source
> data were unmappable because they didn't support a sufficiently
> detailed taxonomy of landcover, and I wanted to point out that "no
> trees here" is useful information that should be distinguished from
> "we haven't yet looked to see if there are trees here."
> 
> "was:landcover=trees" is not something that I favour, because there's
> also the useful combination, "no trees in the old imagery, and no
> trees in the current imagery either", still without information about
> whether one is looking at grass, scrub, heath, meadow, wetland or
> farmland, which can't always be distinguished in orthoimages.  I
> suppose that the "no:landcover=trees" COULD work, but I don't see
> no:*=* in wide use, and suspect that it will be controversial.
> 

Why not landcover=vegetation as an equivalent to highway=road? It would 
indicate that some type of plant matter is growing on it but exactly what is 
not yet known. Once more information (field survey? low level aerial 
survey/photos?) is available then a more specific landcover could be applied.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping deforestation wikipage

[Kevin Kenny]

On Thu, Mar 14, 2019 at 4:51 PM marc marc  wrote:
> no:landcover=trees ?
> or, as the previous landcover/imagery show tress, was:landcover=trees

However you want to spell it.

I just saw two replies to Lorenzo that were suggesting that his source
data were unmappable because they didn't support a sufficiently
detailed taxonomy of landcover, and I wanted to point out that "no
trees here" is useful information that should be distinguished from
"we haven't yet looked to see if there are trees here."

"was:landcover=trees" is not something that I favour, because there's
also the useful combination, "no trees in the old imagery, and no
trees in the current imagery either", still without information about
whether one is looking at grass, scrub, heath, meadow, wetland or
farmland, which can't always be distinguished in orthoimages.  I
suppose that the "no:landcover=trees" COULD work, but I don't see
no:*=* in wide use, and suspect that it will be controversial.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping deforestation wikipage

[marc marc]

Le 14.03.19 à 21:47, Kevin Kenny a écrit :
> there's no way to distinguish, 
> "we haven't read and mapped the imagery yet" from
> "we've mapped the imagery, and there's no forest here."

no:landcover=trees ?
or, as the previous landcover/imagery show tress, was:landcover=trees
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping deforestation wikipage

[Kevin Kenny]

On Thu, Mar 14, 2019 at 4:37 PM Mateusz Konieczny
 wrote:
> I would advise to tag just forest landcover is satellite images are unusable 
> to tag
> other features properly and to not introduce incompatible tagging scheme just 
> because
> you really want to vectorize this specific low quality dataset.

I think there is some grain of value here.  He has a use case where he
has valid but incomplete information: "in this polygon, I don't know
what the landcover is in sufficientdetail to tag it with the existing
OSM taxonomy, but it is definitely NOT forest." Otherwise, there's no
way to distinguish, "we haven't read and mapped the imagery yet" from
"we've mapped the imagery, and there's no forest here."

When I know something about a piece of ground, I think it's reasonable
for me to want to tag what I know, without needing to do further
investigation. That's why, for instance, I object to distinguishing
power=line from power=minor_line by voltage - I may have no way of
determining that in the field, but the power line is still a landmark,
and still deserves to be mapped.

I'm not demanding that for the specific use case of 'NOT forest', that
we have to have a broadly accepted tag, but I think that it may well
be a valid reason to invoke "Any tags you like"
https://wiki.openstreetmap.org/wiki/Any_tags_you_like. It's really
offensive to tell mappers that they can't map features because we
can't figure out how to tag them, and in many cases it comes across as
cultural insensitivity: "the data model is fine. Fix your country."

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping deforestation wikipage

[Mateusz Konieczny]

Mar 14, 2019, 9:28 PM by lorenzostucch...@outlook.it:

> From previous messages we think to change the different tag from landcover to 
> hrg_landcover, the idea came form the professor Brovelli. Because we can 
> think every type of landcover came from a satellite and the HRGLandCover 
> (High Resolution Global Land Cover) is more related to the idea that we want 
> to propose.
>
how "High Resolution Global Land Cover" differs from regular landcover?

As far as I see there is no good reason for introducing new tagging scheme -
it will be either used in one organized editing and later forgotten or, what 
would be worse,
we will have yet another competing scheme duplicating existing ones.

I would advise to tag just forest landcover is satellite images are unusable to 
tag
other features properly and to not introduce incompatible tagging scheme just 
because
you really want to vectorize this specific low quality dataset.

And if you really, really want to vectorize this specific dataset in way 
incompatible with existing OSM
tagging then please avoid saving it in OSM database.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Status of oneway=cw oneway=ccw

[Kevin Kenny]

On Thu, Mar 14, 2019 at 4:33 PM Volker Schmidt  wrote:
> I second Martin. No "oneway" key in this case.
However you want to spell it. Given that the circular route I had in
mind was subsequently signed in the opposite direction, I haven't got
a use case at the moment. (The nearest thing I've got is foot trails
that run both ways over what are one-way snowmobile trails in the
winter, but I know how to represent those.)

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping deforestation wikipage

[marc marc]

that look like a bad idea, let's me explain with some ex
hrg_landcover for HRGLandCover
a made a survey ? surv_landcover
a use mapilary ? mpl_landcover ?
of course not... fill changeset source in stead of duplicate a tag 
depending of the source

Le 14.03.19 à 21:28, Lorenzo Stucchi a écrit :
> Hi,
> 
> thanks for your ideas.
> 
>  From previous messages we think to change the different tag from 
> landcover to hrg_landcover, the idea came form the professor Brovelli. 
> Because we can think every type of landcover came from a satellite and 
> the HRGLandCover (High Resolution Global Land Cover) is more related to 
> the idea that we want to propose.
> 
> Having that idea, we think that the creation of the tag 
> org_landcover=barren can be very useful.
> 
> For what concerns the vegetation if the original sense of the two tag is 
> losted we consider the don’t create the tag.
> 
> Let us known.
> Best,
> Lorenzo
> 
>> Il giorno 14 mar 2019, alle ore 14:00, Mateusz Konieczny 
>> mailto:matkoni...@tutanota.com>> ha scritto:
>>
>> > This can be hard to identify in large area with not optimal images
>> > so the proposal is to create the tag landcover=barren.
>>
>> If things can not be tagged from aerial images then it is better to 
>> wait for new ones
>> rather than add something like that.
>>
>> > Two types of classifications exist:
>> > natural=wood for not managed woods like for the main part of the 
>> Amazonia.
>> > landuse=forest for managed woods maintained by humans.
>>
>> both are simply used for tree-covered areas, and distinction between 
>> them is
>> either ignored or interpreted in some many ways that it is simply 
>> meaningless
>> (note many natural=wood in Europe, where it is hard to find forest not 
>> maintained by humans)
>>
>> > Also, this information partially needed a local knowledge so the 
>> more general
>> > tag used can be landcover=trees, also quite used as shown in taginfo.
>>
>> Landcover trees is a rarely used tag, with over half of use in 
>> Paraguay that is
>> result of single series of edits. It is used by tiny minority of mappers.
>>
>> https://taginfo.openstreetmap.org/tags/landuse=forest
>> https://taginfo.openstreetmap.org/tags/natural=wood
>> https://taginfo.openstreetmap.org/tags/landcover=trees
>>
>>
>>
>> Mar 13, 2019, 8:49 PM by lorenzostucch...@outlook.it 
>> :
>>
>> Hi all,
>>
>> After some discussion about the idea of this project, we think to
>> better capt all the idea to create a wiki page with the purpose of
>> better understand the problem and find the better way to tag this
>> situation.
>>
>> So we create a wiki page
>> https://wiki.openstreetmap.org/wiki/PoliMappers/mapping_deforestation 
>> where
>> is possible to discuss these thematics, let us known your idea.
>>
>> Best Regards,
>> Stucchi Lorenzo
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/tagging
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Status of oneway=cw oneway=ccw

[Volker Schmidt]

I second Martin. No "oneway" key in this case.

On Thu, 14 Mar 2019 at 21:18, Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 14. Mar 2019, at 11:43, Sarah Hoffmann  wrote:
> >
> > or oneway=signed if you think it clashes with the legal
> > restriction tags).
>
>
> or bidirectional=no
> or signed_oneway=yes
>
> it shouldn’t be a value of the “oneway” key, there’s nothing preventing
> you from doing the route in the counterdirection, especially if you are
> with a map from OpenStreetMap ;-)
>
> Yes, it could be interesting to store that the signs work only for one
> direction, but this is very different from a oneway.
>
>
> Cheers, Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Status of oneway=cw oneway=ccw

[Kevin Kenny]

On Thu, Mar 14, 2019 at 10:39 AM Kevin Kenny  wrote:
> The order of ways in the relation definitely determines the direction
> to which oneway=* refers. It oneway=yes or oneway=signed (or whatever
> we settle on) is present, the ways are traversed from the first
> relation member to last - irrespective of the direction of the way.

And I just realized where this rule needs *something* to resolve a
possible ambiguity:

We already have concluded that the direction a route traverses a way
needs to be independent of the direction of the way. (I have examples
where two routes share one way in the same direction, and elsewhere
share a different way in opposite directions, and that's not
achievable otherwise.)

If a route is circular, and the relation has fewer than three ways,
there's then an ambiguity.  For a single way in the relation, the
direction of travel could be either with or against the way.  For a
relation with two ways, the direction of travel on the first way could
be either with or against the way, and in either case, the other way
will have an endpoint that joins and the route will close.

The first case is just a closed way, and the route provides no
indication of the direction of travel.

The second case is that there are ways x and y joining nodes A and B.
The direction of the ways in a route relation, we've already
established, needs to be ignored. So the actual route will depend on
the choice of which end of 'x' is chosen as the start.  It could be B
-> x-in-reverse -> A -> y -> B, or A -> x -> B -> y-in-reverse -> A.
Both routings visit way x before way y, so the order of the ways in
the relation doesn't determine the route.

For three or more ways, there's no ambiguity, since only one endpoint
of the first way will join to the second, determining the direction of
travel on both.

The simplest solution is to require that the ways be split if
necessary to avoid ambiguity - forbid one-way routes of fewer than
three members. An alternative is what I mentioned previously,
disambiguate with 'forward' or 'backward' roles on the ways.  I can
live with either.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping deforestation wikipage

[Lorenzo Stucchi]

Hi,

thanks for your ideas.

From previous messages we think to change the different tag from landcover to 
hrg_landcover, the idea came form the professor Brovelli. Because we can think 
every type of landcover came from a satellite and the HRGLandCover (High 
Resolution Global Land Cover) is more related to the idea that we want to 
propose.

Having that idea, we think that the creation of the tag org_landcover=barren 
can be very useful.

For what concerns the vegetation if the original sense of the two tag is losted 
we consider the don’t create the tag.

Let us known.
Best,
Lorenzo

Il giorno 14 mar 2019, alle ore 14:00, Mateusz Konieczny 
mailto:matkoni...@tutanota.com>> ha scritto:

> This can be hard to identify in large area with not optimal images
> so the proposal is to create the tag landcover=barren.

If things can not be tagged from aerial images then it is better to wait for 
new ones
rather than add something like that.

> Two types of classifications exist:
> natural=wood for not managed woods like for the main part of the Amazonia.
> landuse=forest for managed woods maintained by humans.

both are simply used for tree-covered areas, and distinction between them is
either ignored or interpreted in some many ways that it is simply meaningless
(note many natural=wood in Europe, where it is hard to find forest not 
maintained by humans)

> Also, this information partially needed a local knowledge so the more general
> tag used can be landcover=trees, also quite used as shown in taginfo.

Landcover trees is a rarely used tag, with over half of use in Paraguay that is
result of single series of edits. It is used by tiny minority of mappers.

https://taginfo.openstreetmap.org/tags/landuse=forest
https://taginfo.openstreetmap.org/tags/natural=wood
https://taginfo.openstreetmap.org/tags/landcover=trees



Mar 13, 2019, 8:49 PM by 
lorenzostucch...@outlook.it:
Hi all,

After some discussion about the idea of this project, we think to better capt 
all the idea to create a wiki page with the purpose of better understand the 
problem and find the better way to tag this situation.

So we create a wiki page 
https://wiki.openstreetmap.org/wiki/PoliMappers/mapping_deforestation where is 
possible to discuss these thematics, let us known your idea.

Best Regards,
Stucchi Lorenzo

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Status of oneway=cw oneway=ccw

[Martin Koppenhoefer]

sent from a phone

> On 14. Mar 2019, at 11:43, Sarah Hoffmann  wrote:
> 
> or oneway=signed if you think it clashes with the legal
> restriction tags).


or bidirectional=no
or signed_oneway=yes

it shouldn’t be a value of the “oneway” key, there’s nothing preventing you 
from doing the route in the counterdirection, especially if you are with a map 
from OpenStreetMap ;-)

Yes, it could be interesting to store that the signs work only for one 
direction, but this is very different from a oneway. 


Cheers, Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Paul Allen]

On Thu, 14 Mar 2019 at 19:23, Peter Elderson  wrote:

> Op do 14 mrt. 2019 om 18:17 schreef Paul Allen :
>
>> On Thu, 14 Mar 2019 at 15:09, Jo  wrote:
>>
>>> I would definitely want routes to be composed of subroutes which are
>>> shared with other routes,
>>>
>>
>> I see that as less than useful for any route I know of.
>>
>
> It's useful for longer routes through walking/cycling node networks, using
> the network signposting.
>

Yeah, I can see it would be.  And for longer bus routes.  Just not for any
of the bus routes I know
around here and am likely to map.  You end up with the only common segments
being very short
around a central bus station, then they all diverge.  Once diverged, there
is nothing to share.

I'm not against such sharing in principle, where it makes sense.  But if it
comes at the price
that all bus stops have to be in the aggregate relation and not in the
subroutes then it becomes
useless for my purposes.  And I freely admit that my purposes are a fairly
rare case, but I'd
still like to handle it.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Peter Elderson]

Op do 14 mrt. 2019 om 18:17 schreef Paul Allen :

> On Thu, 14 Mar 2019 at 15:09, Jo  wrote:
>
>> I would definitely want routes to be composed of subroutes which are
>> shared with other routes,
>>
>
> I see that as less than useful for any route I know of.
>

It's useful for longer routes through walking/cycling node networks, using
the network signposting.

Fr gr Peter Elderson


Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - police=*

[marc marc]

Le 14.03.19 à 19:43, Markus a écrit :
> This is why i'm unsure whether it's sensible 
> to introduce a new tag for police stations.

I didn't check if the propal have been update right now
but imho it's better to split out police station.

it's allow to check if ppl like all other items and vote on it.
because you often seen negative vote related to "tag ith high usage 
should no longer be modified for eternity" (irony is voluntary to show 
my disagreement with this argument. if the new scheme brings added value 
to the old one, there is no reason to keep the old one... it is just 
necessary to plan a difficult transition period... which is better in a 
dedicated propal)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - police=*

[Jan S]

Am 14. März 2019 19:43:52 MEZ schrieb Markus :
>On Sat, 9 Mar 2019 at 23:11, Jan S  wrote:
>>
>> I'll collect more opinions on the abolition of amenity=police.
>
>Note that every software that uses OSM data would need to be updated
>before amenity=police can be removed. Therefore it is is unlikely that
>amenity=police would disappear soon. Instead, people would have to
>double-tag police stations as amenity=police + police=station in order
>to comply with both the old and the new scheme. This is why i'm unsure
>whether it's sensible to introduce a new tag for police stations.

I know. That's why I had asked earlier whether it would be better to establish 
a completely new police-tag for all police facilities (probably with 
double-tagging of police stations during a period of adaptation) or to maintain 
amenity=police for police stations and establish the police-tag only for all 
other facilities.

I'm still in favour of the first option. It requires retagging, but we'd end up 
with a neat and consistent tagging scheme. And software could map 
amenity=police and police=station as the same. amenity=police would thus slowly 
be phased out and not have to be eliminated completely in one stroke.

If this seems viable, I would expand the proposal by a migration proposal from 
amenity=police to police=station.

Best, Jan

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - police=*

[Markus]

On Sat, 9 Mar 2019 at 23:11, Jan S  wrote:
>
> I'll collect more opinions on the abolition of amenity=police.

Note that every software that uses OSM data would need to be updated
before amenity=police can be removed. Therefore it is is unlikely that
amenity=police would disappear soon. Instead, people would have to
double-tag police stations as amenity=police + police=station in order
to comply with both the old and the new scheme. This is why i'm unsure
whether it's sensible to introduce a new tag for police stations.

Regards

Markus

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Paul Allen]

On Thu, 14 Mar 2019 at 16:44, Martin Koppenhoefer 
wrote:

>
> > On 14. Mar 2019, at 16:49, Tony Shield  wrote:
> >
> > Can they currently be edited with JOSM?
>
>
> of course, you simply add a relation as member to another relation.
>

Can you?  It's not clear to me from the documentation that I can do that in
a way that achieves what
I want to do and is compatible with accepted usage.  If you can tell me how
to do that I'll be very
happy.

Let me be clear.  I want to decompose a route into segments and then
construct some sort of
relation (ordinary, superroute or whatever) that assembles them in
sequence.  I want to do this
because I have a route which traverses some ways twice.  I want to do this
because the same route
has ways which are traversed twice (A, B, C, D) but the first time the stop
at C is ignored (you can
neither board nor alight there) and the second time the stop at C is usable
(you can board or alight).
I want to do this because although the route is circular, it is "hairy" (in
the mathematical sense), it's
not an "O" but an "O=".  The same way is traversed twice in opposite
directions: in a non-circular
route that would be two variants of a route master but this is a circular
route.

Being able to decompose the route solves several problems.  As a single
route it is a real pain
to edit because the tools don't fully support the same way appearing twice
(maybe there's a JOSM
plugin that does it better).  I still have a gap on the route according to
JOSM validator but I
can't spot it.  It doesn't show as a red dot in the edit relation table, I
can't see it by scrolling through
the list of ways and looking at them, when I go to the validator and try
zooming to the problem
nothing happens.  It's in one of the ways that gets traversed twice and
it's driving me crazy.  I think
that subroutes would make it a lot easier for me to zero in on the problem.

As a single route it's impossible to figure out by simple inspection of the
query tool:
https://www.openstreetmap.org/relation/8592409#map=14/52.0860/-4.6644
You tell me where it goes in what sequence without delving deeply into the
relation.  I'll give
you a hint: it starts and ends here:
https://www.openstreetmap.org/node/3642998002
Want another hint?  It doesn't just start and end there, it also stops
there in the middle of its
route.  Without looking at the details of the relation, tell me where it
goes next after that
starting point.  Being able to decompose it into segments would allow
people to see a
sequence of segments in order (such as via umap) and it would be obvious
what the route
is.  Having segments would allow me to deal with the stop that is passed
twice (in the same
direction) but is only used once - it would appear on one segment but not
the other.

So I don't care if it's a superroute, a master relation (I'm not keen on
that because this route
has several variants so I'd end up with a master relation of variants that
are themselves master
relations of segments), or something else.  I'd just like to be able to do
it.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - police=*

[Jan S]

There have been no further comments on the proposal for several days now, 
neither were there comments on the proposal page. Would it be an issue if I 
started the voting this weekend although the proposal is less than two weeks 
old?

Best, Jan

Am 11. März 2019 17:32:13 MEZ schrieb Martin Koppenhoefer 
:
>
>
>sent from a phone
>
>> On 10. Mar 2019, at 19:07, Andy Townsend  wrote:
>> 
>> That difference might confuse  - that's an American rather than a UK
>difference, I think.  Where "jail" (or even "gaol") is used in the UK
>it's essentially a synonym for prison. 
>
>
>in Germany, the cells in a police facility would not be called a
>prison, AFAIK there are only “drunk tanks” (Ausnüchterungszelle /
>sobering cell) and people would otherwise (pre-trial detention) go to a
>real prison (government facility / de: JVA). There are also other
>places where people are forcibly confined which aren’t “prisons”, e.g.
>psychiatric hospitals and nursing homes. 
>
>Cheers, Martin 
>___
>Tagging mailing list
>Tagging@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk] Tagging disputed boundaries

[Jan S]

Am 14. März 2019 01:02:56 MEZ schrieb Sergio Manzi :
>On 2019-03-14 00:26, Graeme Fitzpatrick wrote:
>>
>> On Thu, 14 Mar 2019 at 08:06, Sergio Manzi > wrote:
>>
>>
>> I was advicing somebody something completely different as of
>lately: to form a hidden, underground, group of motivated persons to
>draft proposals that are already agreed upon by at least "some" before
>going public with the proposal...
>>
>> Your opinion?
>>
>>
>> Did see that, & thought Hmmm?
>>
>> The problem I can see, & yes, of course there'll be ways around it,
>is how do you pick their conspirators collaborators team?
>>
>> Do you stick up a post saying I'm thinking about a new way of mapping
>disputed boundaries, anybody interested please contact me privately, or
>do you send private messages to me, Joseph, Kevin, Dave etc etc to say
>the same thing?

That somehow sounds like the working group I had brought up earlier. I think 
its a good way to proceed on fundamental and complex issues.

It wouldn't have to be secret group though. A call for participants and then a 
list of participants could be published on the proposal page. Also, and in 
general, proposals should, IMO, be linked on the wiki pages that are concerned, 
so as to raise more attention and more participation in the voting process.

Maybe it would be viable to initially propose that a complex situation is to be 
resolved and that a working group shall be established to that end. Thus, 
people don't have to vote complex proposals but rather only determine that an 
issue is complex and that a working group shall be conformed to resolve it.

The (working/secret ;)) group would then develop a solution that would have to 
be approved by simple majority of the votes cast (with working group members 
excluded from voting). A qualified majority as in individual proposals doesn't 
seem to be necessary to be, because a working-group proposal is more reliable 
than individual proposals and thus doesn't require the same level of approval 
by the community.

This procedure is more complex than that for individual proposals. It also 
presupposes a degree of confidence in the work of the group. But it might be a 
way to get better results for complicated problems.

Best, Jan

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Paul Allen]

On Thu, 14 Mar 2019 at 15:09, Jo  wrote:

> I would definitely want routes to be composed of subroutes which are
> shared with other routes,
>

I see that as less than useful for any route I know of.  But I suppose it's
a matter of how short
a subroute you're willing to put up with.  I probably wouldn't do it myself
but would say that you
should not.  However, surely that means that the subroutes also have to be
anonymous (they
don't specify a ref or anything else specific to a particular route) and
would therefore be totally
unsuitable for me.  If that's the case then I'm not in favour of doing
things your way.


> hence the reasoning of keeping the stop sequences in the route relations.
>

That, as I understand it, goes against what is currently done in
superroutes, goes totally
against one of my main reasons for wanting to do this, and makes editing
far harder.  Keeping
the stops with the route segment makes sense for many reasons.  It means
subroutes can
be edited independently of one another.  It makes adding/removing stops
easier for the simple
reason that it's easier to figure out where a stop goes in a relatively
short subroute than on
a much longer superroute.  It means the standard carto query on a subroute
shows the stops
associated with that subroute whereas your way you'd have to query the
superroute to see
the entire route and all its stops in order to see the stops on a much
smaller subroute.

All in all, I think keeping stops in the superroute is a very bad way to
go, independent of it
achieving precisely the opposite of what I hope to do.

Your "enhancement" makes the whole idea useless for my purposes and, I
think, is impracticl
for any other purpose.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Martin Koppenhoefer]

sent from a phone

> On 14. Mar 2019, at 16:49, Tony Shield  wrote:
> 
> Can they currently be edited with JOSM?


of course, you simply add a relation as member to another relation.

Cheers, Martin 

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Tony Shield]

Hi

Is there a PTV2 example of route with ways and subroutes? Can they 
currently be edited with JOSM?


TonyS

On 14/03/2019 15:07, Jo wrote:
I would definitely want routes to be composed of subroutes which are 
shared with other routes, hence the reasoning of keeping the stop 
sequences in the route relations.


Polyglot

On Thu, Mar 14, 2019, 15:41 Paul Allen  wrote:


On Thu, 14 Mar 2019 at 11:21, Tony Shield
mailto:tony.shield...@gmail.com>> wrote:

Am I right in thinking that a superroute is a sequence of ways
and relations of ways?


I'm not 100% certain.  The documentation on the wiki isn't
entirely clear.  I suspect some of it
may have been scrubbed by those who dislike the concept of
superroutes for any purpose
whatsoever, but it may just never have been written in the first
place.

As I understand it (possibly entirely inccorectly) it would be
analogous (using a slightly
different mechanism) to having the Wales Coast Path be a relation
comprising the
route for the Pembrokeshire Coast Path, the Ceredigion Coast Path,
etc.  A relation of
relations.

The relation of ways could be called a route-segment or
similar. A I see it routes for most trains and buses are a
sequence of ways and route-segments, and a route-segment could
be used by many routes.


I wasn't intending to share segments between routes.  I'm not sure
if I could make that work for
some of my purposes (I haven't thought about it enough to be
sure).  It probably won't be
universally applicable anyway, there are going to be routes that
share a particular segment but
not all of the stops on that segment.  Also fan-out of routes is
going to result in a lot of very
tiny segments that are possibly more trouble than they're worth
and it's probably less work to
make them longer segments.

-- 
Paul


___
Tagging mailing list
Tagging@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/tagging


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Jo]

I would definitely want routes to be composed of subroutes which are shared
with other routes, hence the reasoning of keeping the stop sequences in the
route relations.

Polyglot

On Thu, Mar 14, 2019, 15:41 Paul Allen  On Thu, 14 Mar 2019 at 11:21, Tony Shield 
> wrote:
>
> Am I right in thinking that a superroute is a sequence of ways and
>> relations of ways?
>>
>
> I'm not 100% certain.  The documentation on the wiki isn't entirely
> clear.  I suspect some of it
> may have been scrubbed by those who dislike the concept of superroutes for
> any purpose
> whatsoever, but it may just never have been written in the first place.
>
> As I understand it (possibly entirely inccorectly) it would be analogous
> (using a slightly
> different mechanism) to having the Wales Coast Path be a relation
> comprising the
> route for the Pembrokeshire Coast Path, the Ceredigion Coast Path, etc.  A
> relation of
> relations.
>
>
>> The relation of ways could be called a route-segment or similar. A I see
>> it routes for most trains and buses are a sequence of ways and
>> route-segments, and a route-segment could be used by many routes.
>>
>
> I wasn't intending to share segments between routes.  I'm not sure if I
> could make that work for
> some of my purposes (I haven't thought about it enough to be sure).  It
> probably won't be
> universally applicable anyway, there are going to be routes that share a
> particular segment but
> not all of the stops on that segment.  Also fan-out of routes is going to
> result in a lot of very
> tiny segments that are possibly more trouble than they're worth and it's
> probably less work to
> make them longer segments.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Paul Allen]

On Thu, 14 Mar 2019 at 11:21, Tony Shield  wrote:

Am I right in thinking that a superroute is a sequence of ways and
> relations of ways?
>

I'm not 100% certain.  The documentation on the wiki isn't entirely clear.
I suspect some of it
may have been scrubbed by those who dislike the concept of superroutes for
any purpose
whatsoever, but it may just never have been written in the first place.

As I understand it (possibly entirely inccorectly) it would be analogous
(using a slightly
different mechanism) to having the Wales Coast Path be a relation
comprising the
route for the Pembrokeshire Coast Path, the Ceredigion Coast Path, etc.  A
relation of
relations.


> The relation of ways could be called a route-segment or similar. A I see
> it routes for most trains and buses are a sequence of ways and
> route-segments, and a route-segment could be used by many routes.
>

I wasn't intending to share segments between routes.  I'm not sure if I
could make that work for
some of my purposes (I haven't thought about it enough to be sure).  It
probably won't be
universally applicable anyway, there are going to be routes that share a
particular segment but
not all of the stops on that segment.  Also fan-out of routes is going to
result in a lot of very
tiny segments that are possibly more trouble than they're worth and it's
probably less work to
make them longer segments.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Status of oneway=cw oneway=ccw

[Kevin Kenny]

On Thu, Mar 14, 2019 at 6:45 AM Sarah Hoffmann  wrote:
> I was pointed to the discussion from the waymarkedtrails issue
> tracker. I haven't followed the whole discussion. Here's just my
> two cents as somebody how processes route data.

I know that you and I have pretty strong disagreements on the
processing of route data (mostly owing, I think, to the ridiculously
high number of route concurrences in the US), but on this specific
issue, I think we're in 'violent agreement'.

oneway=* definitely goes on the relation, not on the member ways, for
the case where a route runs only one way by convention, but the
individual ways can be followed in either direction, physically and
legally.

The order of ways in the relation definitely determines the direction
to which oneway=* refers. It oneway=yes or oneway=signed (or whatever
we settle on) is present, the ways are traversed from the first
relation member to last - irrespective of the direction of the way.

I'm aware of what 'forward' and 'backward' are intended to mean - it's
there to handle cases like a pair of one-way streets that belong to
the same numbered route, or the two ways of a dual carriageway. When I
suggested borrowing this tagging for the one-way route, I thought it
was Mostly Harmless to do so, because in this case, the way only
exists in one direction. Navigation engines honor the 'forward' and
'backward' values (to avoid sending you on the wrong direction of a
route - some routes separate into 'forward' and 'backward' on two-way
streets, to avoid illegal turns or something), and so I thought that
the explicit direction would be a little extra level of safety against
misrouting. It doesn't exactly misinform, because as I said, the route
doesn't exist in the opposite direction.

I concede that nearly everything can work without the explicit
'forward' and 'backward' indicating whether the route runs with or
against the direction of the way.

I think we both agree that oneway=cw and oneway=ccw are difficult for
both navigation and rendering, and hope we can lay those to rest.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Paul Allen]

On Thu, 14 Mar 2019 at 03:44, Warin <61sundow...@gmail.com> wrote:

> On 14/03/19 01:02, Paul Allen wrote:
>
>
>
> One problem that I don't see a solution for in PTV1, PTV2 or "we don't tag
> it PTV3" is a stop
> that is ignored on the first pass but comes into play on the second pass.
> The bus starts at
> the bus station A, passes through nodes B, C and D and turns right at D to
> E.  On this pass
> through C it ignores the bus stop there.  After it's gone through the
> alphabet back to A, it
> again goes through B, C and D but this time turns left to alpha, beta,
> etc.  On this pass it
> does stop at C.  Piling all the stops into the relation may lead the
> routers to conclude that
> you can wait at the stop C to get directly to E when you can't (but you
> can get on at C to take
> a detour through the greek alphabet and eventually get to E because it's a
> circular).
>
> IN PTV2 you list the stops in order .. so they would be listed as;
> A
> B
> D
> E
> etc
> A
> B
> C
> D
> E
> etc
>
> So it can be done in PTV2.
>

Yes, it can be done.  I said as much myself.  But it is hard to decipher.
There is nothing that
explicitly says that the bus does not  stop at C the first time the bus
passes it but does stop
the second time.  If you painfully trace out the ENTIRE route, correlating
stops and ways,
you can reach the correct conclusion.

Now consider somebody using the query tool for the bus stop at C.  Somebody
who isn't a
mapper, just a user.  Here's the route:
https://www.openstreetmap.org/relation/8592409#map=14/52.0860/-4.6644
and here's the stop: https://www.openstreetmap.org/node/5706768172 Note
that I haven't yet
included the stop on that route (although I have included it in an
incomplete variant route), but
if I had, and included it in the right order, how easy would it be for you
to figure out what is going on?
>From casual inspection, it's not easy.

However, take a look at the incomplete variant route:
https://www.openstreetmap.org/relation/8603360#map=14/52.0869/-4.6691
and imagine that were part of a superroute.  You could see, by inspecting
the subroutes in turn
(for example, on umap) that this stop is used on one route segment but not
another, even though
both segments pass along that way.

A segment end does not indicate a stop .. in PTV2. The segments need to be
> in sequential order and so do the stops.
>

A segment END?  Who's talking about segment ends?  I'm talking about a
segment which may
have more than one stop or no stops at all.  Who's talking about disordered
segments?  The whole
idea is to have the segments in order.  Who's talking about disordered
stops?  The whole idea is
to have ordered stops.

What I'm talking about is a segment of a route with its stops.  It may
share one or more ways
with a different segments of that route, and it may share one or more stops
(or none at all).  One
of us is missing what the other is saying, right now I don't know which one
of us that is.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping deforestation wikipage

[Mateusz Konieczny]

> This can be hard to identify in large area with not optimal images 
> so the proposal is to create the tag landcover=barren. 

If things can not be tagged from aerial images then it is better to wait for 
new ones 
rather than add something like that.

> Two types of classifications exist:
> natural=wood for not managed woods like for the main part of the Amazonia.
> landuse=forest for managed woods maintained by humans.

both are simply used for tree-covered areas, and distinction between them is
either ignored or interpreted in some many ways that it is simply meaningless
(note many natural=wood in Europe, where it is hard to find forest not 
maintained by humans)

> Also, this information partially needed a local knowledge so the more general 
> tag used can be landcover=trees, also quite used as shown in taginfo. 

Landcover trees is a rarely used tag, with over half of use in Paraguay that is
result of single series of edits. It is used by tiny minority of mappers.

https://taginfo.openstreetmap.org/tags/landuse=forest 

https://taginfo.openstreetmap.org/tags/natural=wood 

https://taginfo.openstreetmap.org/tags/landcover=trees



Mar 13, 2019, 8:49 PM by lorenzostucch...@outlook.it:

> Hi all,
>
> After some discussion about the idea of this project, we think to better capt 
> all the idea to create a wiki page with the purpose of better understand the 
> problem and find the better way to tag this situation.
>
> So we create a wiki page >  
> https://wiki.openstreetmap.org/wiki/PoliMappers/mapping_deforestation 
> >  
> where is possible to discuss these thematics, let us known your idea.
>
> Best Regards,
> Stucchi Lorenzo
>

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk] Tagging disputed boundaries

[Mateusz Konieczny]

Mar 14, 2019, 12:03 AM by joseph.eisenb...@gmail.com:

> > “> form a hidden, underground, group of motivated persons to draft 
> > proposals”
>
> 臘‍♂️
>
> I might support this if all men, Europeans, and people of European ancestry 
> were excluded from this cabal of illuminati. 
>

Proposing discrimination, even framed as jokes, is quite undesirable. Please 
stop doing this.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping deforestation wikipage

[Mateusz Konieczny]

In my experience this kind of "lets drop bunch of fixmes and others will map it 
properly"
leads to nothing good.

It is better to map less but properly rather than add low quality data.

Mar 14, 2019, 10:50 AM by lorenzostucch...@outlook.it:

> Hi, 
>
> thanks for your very interesting point, this can be a good point to thinks to 
> pass to the tag landcover to sat_landcover to better distinguish the 
> different vision. And sat_landcover can be a first draft info just for 
> isolated land where is hard to go and check what is mapped and after this 
> info can be implemented
>

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Expand the key:opening_hours

[Simon Poole]

Some more comments:

- the OH values are currently always evaluated in the local time zone
(or to go even a bit further in a local context as the location they
apply to is always known), so a time zone indicator would be only needed
in the cases that require different processing, the question is if that
is common enough to justify the additional complication.

- Summer and winter solstice can be, as far as I can see, modelled as
additional variable_date values (currently only "easter" is defined), I
would avoid qualifying them with months as again, that require parser
changes that will cause issues.

- Lunar months: are there any common names for these instead of just
numbering? And how are the "leap" variants supposed to be different?

Simon

Am 14.03.2019 um 02:03 schrieb Phake Nick:
> Separating it from the current system might have the advantage that it
> will not need to use the same syntax to support all regional specific
> methods of day counting and time counting at once, but even after
> separated it will still need to support the full set of current
> opening_time specification in addition to those regional
> specifications.
>
> Warin <61sundow...@gmail.com> 於 2019年3月14日週四 上午8:29寫道：
>> On 14/03/19 10:52, Simon Poole wrote:
>>> Just a PS: any grammar extension need to be compatible with the use of
>>> OH strings in conditional restrictions too, see
>>> https://wiki.openstreetmap.org/wiki/Conditional_restrictions . While I
>>> haven't looked at in detail your proposal for a timezone extension
>>> might have difficulties with that.
>>>
>>> Am 14.03.2019 um 00:38 schrieb Simon Poole:
 The basic problem with proposing an extension to the current OH grammar
 is that it is already far too complicated and full of ambiguities, there
 are afaik currently only two parsers that handle > 90% of the grammar
 and most of the other ones are rather broken, adding more stuff is
 definitely not going to improve things.

 That said, there are one or two places where extensions would be low
 impact (extra holiday and variable_date  values for example). However in
 any case I would suggest you familiarize yourself with the actual
 grammar
 https://wiki.openstreetmap.org/wiki/Key:opening_hours/specification
 first , in particular your proposal begins with a couple of non-starters
 that conflict directly with the existing specification.

 Simon

 Am 13.03.2019 um 19:52 schrieb Phake Nick:
> I found that the current way of mapping opening time of features in
> OSM map are too limiting, and the opening time of some features cannot
> be properly represented with only the current syntax, therefore I have
> written a brief idea about how the syntax in key opening_hours could
> have been expanded to match more different needs at the article's talk
> page. 
> Seehttps://wiki.openstreetmap.org/wiki/Talk:Key:opening_hours#Proposed_extension_to_supported_syntax_in_the_page.
> . It would be nice if these features can be added into the scheme so
> that relevant featurs opening days and time can be represented by the
> scheme directly instead of via text description and external link.
>
> The most significant part of what I would like to see are support for
> solar term(節氣/节气/節気/절기/Tiết khí) and (East Asia) lunar (lunisolar)
> calendar(舊曆/旧历/旧暦/음력/Nông lịch). And because the calculation of both
> are dependent on timezone and then when some countries celebrate these
> festivals they use the calendar that is not based on their own
> country's time but use the Chinese time (or time of other countries
> for overseas diaspora of them) so I have also added a proposal to
> support timezone specification in the scheme which is also desired by
> some other users on the talk page. Note that the scheme I proposed to
> express solar term and lunar month representation wasn't actually that
> much intuitive but I believe it have an advantage that it's more
> internationalized and thus providing a common way of tagging features
> across different regions that use the calendar.
>
> Additionally, I have also written in the proposal that I would like to
> see additional supported values for bank holidays, offset in term of
> number of weeks, and also support for timestamp beyond 24 hours in the
> scheme. Expressing time beyond 24 hours can be especially meaningful
> when the operator of those features decided to release their time this
> way and it can reduce error when inputing or transporting data into
> OSM as it is not uncommon for people to forget properly converting
> dates when they are asked to change the time format back to 00-23h
> format.
>
> And while it seems like the de facto standard, I would also like to
> see the formalization of the handling of time range representation
> like Su 23:00-07:00 that in such syntax the 

Re: [Tagging] Superroutes - good, bad or ugly?

[Tony Shield]

Warin

Great description of PTV2.

Paul

Am I right in thinking that a superroute is a sequence of ways and 
relations of ways? The relation of ways could be called a route-segment 
or similar. A I see it routes for most trains and buses are a sequence 
of ways and route-segments, and a route-segment could be used by many 
routes.


TonyS

On 14/03/2019 03:43, Warin wrote:

On 14/03/19 01:02, Paul Allen wrote:



One problem that I don't see a solution for in PTV1, PTV2 or "we 
don't tag it PTV3" is a stop
that is ignored on the first pass but comes into play on the second 
pass.  The bus starts at
the bus station A, passes through nodes B, C and D and turns right at 
D to E.  On this pass
through C it ignores the bus stop there.  After it's gone through the 
alphabet back to A, it
again goes through B, C and D but this time turns left to alpha, 
beta, etc.  On this pass it
does stop at C.  Piling all the stops into the relation may lead the 
routers to conclude that
you can wait at the stop C to get directly to E when you can't (but 
you can get on at C to take
a detour through the greek alphabet and eventually get to E because 
it's a circular).

IN PTV2 you list the stops in order .. so they would be listed as;
A
B
D
E
etc
A
B
C
D
E
etc

So it can be done in PTV2.


Splitting it into route segments would fix the problem with the stop 
at C.  On one segment it isn't

a listed stop.  On another segment it is.


A segment end does not indicate a stop .. in PTV2. The segments need 
to be in sequential order and so do the stops.


I did a rough simpletons guide to PTV2 .. 
https://www.openstreetmap.org/user/Warin61/diary/45106




___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Status of oneway=cw oneway=ccw

[Sarah Hoffmann]

Hi,

I was pointed to the discussion from the waymarkedtrails issue
tracker. I haven't followed the whole discussion. Here's just my
two cents as somebody how processes route data.

On Wed, Mar 13, 2019 at 04:37:19PM +0100, s8evq wrote:
> > If you want to indicate the preferred direction of a walking route that is
> > basically loop-shaped, a concept that is different from the legally binding
> > oneway, then some kind of clockwise / anticlockwise tagging should be used.
> 
> Yes Volcker, this is what I'm after. It's about loop-shaped 
> walking/hiking/cycling routes, that should only by done in one direction, 
> because of way-marking and signposts.  (Most of the bicycle routes in this 
> overpass query fall in that category https://overpass-turbo.eu/s/GWB, quite a 
> lot!)
> I'm not talking about individual ways that are oneway restricted for 
> pedestrians.
> 
> 
> How to properly indicate the preferred direction of this kind of relation? 
> 
> method (1) With proper forward / backward roles on the members of the 
> relation? (as stated in the route=bicycle wiki page 
> https://wiki.openstreetmap.org/wiki/Tag:route%3Dbicycle and mentioned by 
> Volcker Schmidt and Kevin Kenny)

That's for the case where a route forks and follows different
ways for forwards and backward directions of the route. I'd still
expect both directions to be present.

> method (2) By using the tag oneway=yes, (as stated on the route=hiking and 
> route=foot wiki page  https://wiki.openstreetmap.org/wiki/Tag:route%3Dhiking 
> https://wiki.openstreetmap.org/wiki/Tag:route%3Dfoot but it causing a lot of 
> confusion here)
> 
> I have not seen anybody on this mailing list defend the usage of method (2). 
> Can I ask the question: why it is in the wiki?

Then let me defend the method. I like the simple oneway=yes
(or oneway=signed if you think it clashes with the legal
 restriction tags). It is the least hassle for a mapper.
In addition to using the tag  you need to make sure that
your members are correctly ordered in the direction where the
route is signed. Then it is also really easy to determine which
the recommended direction is, if you look at the entire
relation.

NB: There is a bit of a conflict though here between those who
just want to paint the routes on a map and those who want to
process entire routes. For the map creators the forward/backward
solution is much nicer because the role is relative to the way.
It makes it easier to simply add a couple of arrows to indicate
direction. The 'oneway=yes' is a pain because you first need to
determine if the way is forwards or backwards in the relation.
When assembling routes from the relation exactly the opposite
holds. Forward/backwards doesn't give any information about the
direction of the route the way belongs to.

So disclaimer here: I like oneway=yes because waymarkedtrails
fully processes relations.

oneway=cw/ccw might be useful for mappers to verify that the route
is correct but rather difficult for processing.

Sarah


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping deforestation wikipage

[Peter Elderson]

You may want to look at this project:

http://geacron.com/the-geacron-project/

The tool can display/browse historical geo-data as year-to-year browseable
maps. There probably are other tools out there, mayebe even osm-based.
(This is where the real experts kick in...)

Fr gr Peter Elderson


Op do 14 mrt. 2019 om 10:54 schreef Lorenzo Stucchi <
lorenzostucch...@outlook.it>:

> Hi,
>
> thanks for your very interesting point, this can be a good point to thinks
> to pass to the tag landcover to sat_landcover to better distinguish the
> different vision. And sat_landcover can be a first draft info just for
> isolated land where is hard to go and check what is mapped and after this
> info can be implemented
>
> For the changes in time it depends on the availability of the satellite
> imagery. About this I found some old wiki page with some tools for
> understand the time of the Bing imagery, but they doesn’t works anymore.
>
> Best,
> Lorenzo
>
> Il giorno 14 mar 2019, alle ore 09:48, Peter Elderson 
> ha scritto:
>
> I think your idea is good, but the scale and viewpoint are different from
> the regular mapping perspective.
>
> OSM-mappers map "What's on the ground" as seen from the ground, as
> detailed as possible. Satellite imagery is only used to estimate and
> confiirm. Wjhat one doesn't know, is left open. Where there is no
> landcover, no landcover is mapped.
>
> Your idea appears to colour Earth surface in large area's, according to
> predominant cover as seen from satellite. Nothing would remain empty: if
> there is nothing covering the earth, that's what you tag.
>
> I see no way to unite these perspectives in the current landcover, landuse
> and natural tagging. I think you would need a separate special tag for
> this. E.g. sat_landcover=* defined specially for this purpose. Then you can
> define "barren" as a satellite landcover, and you can set up a quality
> assurance system based on systematic review according to satellite imagery.
> Of course, other datausers will be able to use the data for rendering if
> they see fit.
>
> Since it's about changes in the course of time, how do you plan to record
> and display the changes? Yearly datasets?
>
>
> Fr gr Peter Elderson
>
>
> Op do 14 mrt. 2019 om 08:41 schreef Lorenzo Stucchi <
> lorenzostucch...@outlook.it>:
>
>> Hi,
>>
>> Thanks for your reply.
>>
>> Il giorno 14 mar 2019, alle ore 00:43, Warin <61sundow...@gmail.com> ha
>> scritto:
>>
>>
>> A good guide is to only map what you know, if you don't know - leave the
>> map blank. Colouring in the map may look pretty, but it may hide errors
>> that would be best left for others to find having been altered to the area
>> by the blank area.
>>
>>
>> I think that with the propose of mapping deforestation if we add data in
>> this area were the data aren’t present we don’t just coloured the map but
>> we can create a good database, from which is possible to analyse the
>> evolution of the forest area and have the possibility to study better some
>> aspect of climate change.
>>
>>
>> landcover =barren
>> 
>> .
>>
>> NO! This fails to map what is there.
>>
>>  Map the surrounding area with what you can see and leave a hole in it,
>> use a relation to do it of the type=multipolygon.
>>
>>
>> I’m not agree because If we leave a empty area this can be everything
>> that doesn’t have a tag, for example grass land where we are not sure if
>> its grass or meadow, that its hard to distinguish it from the satellite.
>>
>>
>> landcover =artificial
>> 
>>
>> Don't think so. Too general. And the text links it to are 3 land uses,
>> these are not land covers.
>>
>>
>> I’m agree with you that this can be to general, exactly there are 3
>> different tag to tag the area if better quality imagery are available and
>> is possible to distinguish between them.
>>
>>
>> landcover =cultivated
>> .
>>
>> This is not a land cover, it is a land use. And OSM presently prefers a
>> more detailed value.
>>
>>
>> I thinks that this is landcover, also for the reason explained in the
>> introduction and considering the previous scientific studies.
>>
>>
>> landcover =trees
>> 
>> This at least works .. it is a land cover and it does have trees.
>> Unfortunately it does not render on many maps, so you might also tag it
>> natural=wood.
>>
>>
>> Depends what we think that is more interesting the info in the database
>> or the rendering of the map.
>>
>> Thanks for your reply.
>>
>> Best,
>> Lorenzo Stucchi
>>
>> On 14/03/19 06:49, 

Re: [Tagging] Mapping deforestation wikipage

[Lorenzo Stucchi]

Hi,

thanks for your very interesting point, this can be a good point to thinks to 
pass to the tag landcover to sat_landcover to better distinguish the different 
vision. And sat_landcover can be a first draft info just for isolated land 
where is hard to go and check what is mapped and after this info can be 
implemented

For the changes in time it depends on the availability of the satellite 
imagery. About this I found some old wiki page with some tools for understand 
the time of the Bing imagery, but they doesn’t works anymore.

Best,
Lorenzo

Il giorno 14 mar 2019, alle ore 09:48, Peter Elderson 
mailto:pelder...@gmail.com>> ha scritto:

I think your idea is good, but the scale and viewpoint are different from the 
regular mapping perspective.

OSM-mappers map "What's on the ground" as seen from the ground, as detailed as 
possible. Satellite imagery is only used to estimate and confiirm. Wjhat one 
doesn't know, is left open. Where there is no landcover, no landcover is mapped.

Your idea appears to colour Earth surface in large area's, according to 
predominant cover as seen from satellite. Nothing would remain empty: if there 
is nothing covering the earth, that's what you tag.

I see no way to unite these perspectives in the current landcover, landuse and 
natural tagging. I think you would need a separate special tag for this. E.g. 
sat_landcover=* defined specially for this purpose. Then you can define 
"barren" as a satellite landcover, and you can set up a quality assurance 
system based on systematic review according to satellite imagery. Of course, 
other datausers will be able to use the data for rendering if they see fit.

Since it's about changes in the course of time, how do you plan to record and 
display the changes? Yearly datasets?


Fr gr Peter Elderson


Op do 14 mrt. 2019 om 08:41 schreef Lorenzo Stucchi 
mailto:lorenzostucch...@outlook.it>>:
Hi,

Thanks for your reply.

Il giorno 14 mar 2019, alle ore 00:43, Warin 
<61sundow...@gmail.com> ha scritto:


A good guide is to only map what you know, if you don't know - leave the map 
blank. Colouring in the map may look pretty, but it may hide errors that would 
be best left for others to find having been altered to the area by the blank 
area.

I think that with the propose of mapping deforestation if we add data in this 
area were the data aren’t present we don’t just coloured the map but we can 
create a good database, from which is possible to analyse the evolution of the 
forest area and have the possibility to study better some aspect of climate 
change.


landcover=barren.

NO! This fails to map what is there.

 Map the surrounding area with what you can see and leave a hole in it, use a 
relation to do it of the type=multipolygon.

I’m not agree because If we leave a empty area this can be everything that 
doesn’t have a tag, for example grass land where we are not sure if its grass 
or meadow, that its hard to distinguish it from the satellite.


landcover=artificial

Don't think so. Too general. And the text links it to are 3 land uses, these 
are not land covers.

I’m agree with you that this can be to general, exactly there are 3 different 
tag to tag the area if better quality imagery are available and is possible to 
distinguish between them.


landcover=cultivated.
This is not a land cover, it is a land use. And OSM presently prefers a more 
detailed value.

I thinks that this is landcover, also for the reason explained in the 
introduction and considering the previous scientific studies.


landcover=trees
This at least works .. it is a land cover and it does have trees. Unfortunately 
it does not render on many maps, so you might also tag it natural=wood.

Depends what we think that is more interesting the info in the database or the 
rendering of the map.

Thanks for your reply.

Best,
Lorenzo Stucchi

On 14/03/19 06:49, Lorenzo Stucchi wrote:
Hi all,

After some discussion about the idea of this project, we think to better capt 
all the idea to create a wiki page with the purpose of better understand the 
problem and find the better way to tag this situation.

So we create a wiki page 
https://wiki.openstreetmap.org/wiki/PoliMappers/mapping_deforestation where is 
possible to discuss these thematics, let us known your idea.

___
Tagging mailing list
Tagging@openstreetmap.org

Re: [Tagging] Multipolygon (several outers) forest with different leaf_types: mapping strategy?

[Andy Townsend]

On 13/03/2019 13:59, David Marchal wrote:
I mapped a forest made of several pieces of woodland, some contiguous 
and some isolated, with differents leaf_types. I mapped this 
(https://www.openstreetmap.org/relation/9393253) with a landuse=forest 
multipolygon, with common tags such as name and operator on the 
relation, and with leaf_type tags on the outer members, as each has a 
different value. It seemed a good way to model the fact that these 
woodlands were considered part of the same forest but had differents 
leaf_types, but I am unsure now: the JOSM validator claims that 
contiguous outer members is an error, and openstreetmap.org renders a 
misplaced name and no leaf_type. Is it a modelling failure or a 
renderer and validator error? In the first case, how should I map this?


Using a multipolygon relation like this makes sense when the objects are 
exactly the same, but not when they aren't, so that probably explains 
the validator issue.



Name placement on multipolygons like this is actaully a renderer 
decision - some will use one name per group of trees, some one name 
placed somewhere near the biggest.



I'd probably map your trees as either:


1) natural=wood; name=whatever; operator=whatever; leaf_type=whatever on 
each group of trees.  This will result in duplicated names, but isn't 
that different to the way we split roads when other tags change.



or


2) natural=wood; leaf_type=whatever on each group of trees, and create a 
landuse=forest multipolygon relation with name=whatever; 
operator=whatever that includes each group of trees.



or


3) If the "managed forest area" by operator=whatever includes 
significant area of no trees currently, natural=wood; leaf_type=whatever 
on each group of trees, and create a landuse=forestry multipolygon 
relation with name=whatever; operator=whatever that includes each group 
of trees or no trees managed by the same organisation.



The whole landuse=forest/natural=wood thing is fairly contentious 
though, so please don't take the above as "what everyone does in OSM"; 
it's just how I'd map it.



Best Regards,


Andy


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping deforestation wikipage

[Peter Elderson]

I think your idea is good, but the scale and viewpoint are different from
the regular mapping perspective.

OSM-mappers map "What's on the ground" as seen from the ground, as detailed
as possible. Satellite imagery is only used to estimate and confiirm. Wjhat
one doesn't know, is left open. Where there is no landcover, no landcover
is mapped.

Your idea appears to colour Earth surface in large area's, according to
predominant cover as seen from satellite. Nothing would remain empty: if
there is nothing covering the earth, that's what you tag.

I see no way to unite these perspectives in the current landcover, landuse
and natural tagging. I think you would need a separate special tag for
this. E.g. sat_landcover=* defined specially for this purpose. Then you can
define "barren" as a satellite landcover, and you can set up a quality
assurance system based on systematic review according to satellite imagery.
Of course, other datausers will be able to use the data for rendering if
they see fit.

Since it's about changes in the course of time, how do you plan to record
and display the changes? Yearly datasets?


Fr gr Peter Elderson


Op do 14 mrt. 2019 om 08:41 schreef Lorenzo Stucchi <
lorenzostucch...@outlook.it>:

> Hi,
>
> Thanks for your reply.
>
> Il giorno 14 mar 2019, alle ore 00:43, Warin <61sundow...@gmail.com> ha
> scritto:
>
>
> A good guide is to only map what you know, if you don't know - leave the
> map blank. Colouring in the map may look pretty, but it may hide errors
> that would be best left for others to find having been altered to the area
> by the blank area.
>
>
> I think that with the propose of mapping deforestation if we add data in
> this area were the data aren’t present we don’t just coloured the map but
> we can create a good database, from which is possible to analyse the
> evolution of the forest area and have the possibility to study better some
> aspect of climate change.
>
>
> landcover =barren
> 
> .
>
> NO! This fails to map what is there.
>
>  Map the surrounding area with what you can see and leave a hole in it,
> use a relation to do it of the type=multipolygon.
>
>
> I’m not agree because If we leave a empty area this can be everything that
> doesn’t have a tag, for example grass land where we are not sure if its
> grass or meadow, that its hard to distinguish it from the satellite.
>
>
> landcover =artificial
> 
>
> Don't think so. Too general. And the text links it to are 3 land uses,
> these are not land covers.
>
>
> I’m agree with you that this can be to general, exactly there are 3
> different tag to tag the area if better quality imagery are available and
> is possible to distinguish between them.
>
>
> landcover =cultivated
> .
>
> This is not a land cover, it is a land use. And OSM presently prefers a
> more detailed value.
>
>
> I thinks that this is landcover, also for the reason explained in the
> introduction and considering the previous scientific studies.
>
>
> landcover =trees
> 
> This at least works .. it is a land cover and it does have trees.
> Unfortunately it does not render on many maps, so you might also tag it
> natural=wood.
>
>
> Depends what we think that is more interesting the info in the database or
> the rendering of the map.
>
> Thanks for your reply.
>
> Best,
> Lorenzo Stucchi
>
> On 14/03/19 06:49, Lorenzo Stucchi wrote:
>
> Hi all,
>
> After some discussion about the idea of this project, we think to better
> capt all the idea to create a wiki page with the purpose of better
> understand the problem and find the better way to tag this situation.
>
> So we create a wiki page
> https://wiki.openstreetmap.org/wiki/PoliMappers/mapping_deforestation where
> is possible to discuss these thematics, let us known your idea.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Multipolygon (several outers) forest with different leaf_types: mapping strategy?

[Markus]

On Thu, 14 Mar 2019 at 01:24, Warin <61sundow...@gmail.com> wrote:
>
> A site relation could be the best solution?

A group relation [1] seems to be the best fit. This is a relation for
a named group of objects. Unlike a site or multipolygon relation, a
group relation does *not* constitute a new object, but is merely the
name of its members as a whole.

[1]: https://wiki.openstreetmap.org/wiki/Proposed_features/Group_Relation

Regards

Markus

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping deforestation wikipage

[Lorenzo Stucchi]

Hi,

Thanks for your reply.

Il giorno 14 mar 2019, alle ore 00:43, Warin 
<61sundow...@gmail.com> ha scritto:


A good guide is to only map what you know, if you don't know - leave the map 
blank. Colouring in the map may look pretty, but it may hide errors that would 
be best left for others to find having been altered to the area by the blank 
area.

I think that with the propose of mapping deforestation if we add data in this 
area were the data aren’t present we don’t just coloured the map but we can 
create a good database, from which is possible to analyse the evolution of the 
forest area and have the possibility to study better some aspect of climate 
change.


landcover=barren.

NO! This fails to map what is there.

 Map the surrounding area with what you can see and leave a hole in it, use a 
relation to do it of the type=multipolygon.

I’m not agree because If we leave a empty area this can be everything that 
doesn’t have a tag, for example grass land where we are not sure if its grass 
or meadow, that its hard to distinguish it from the satellite.


landcover=artificial

Don't think so. Too general. And the text links it to are 3 land uses, these 
are not land covers.

I’m agree with you that this can be to general, exactly there are 3 different 
tag to tag the area if better quality imagery are available and is possible to 
distinguish between them.


landcover=cultivated.
This is not a land cover, it is a land use. And OSM presently prefers a more 
detailed value.

I thinks that this is landcover, also for the reason explained in the 
introduction and considering the previous scientific studies.


landcover=trees
This at least works .. it is a land cover and it does have trees. Unfortunately 
it does not render on many maps, so you might also tag it natural=wood.

Depends what we think that is more interesting the info in the database or the 
rendering of the map.

Thanks for your reply.

Best,
Lorenzo Stucchi

On 14/03/19 06:49, Lorenzo Stucchi wrote:
Hi all,

After some discussion about the idea of this project, we think to better capt 
all the idea to create a wiki page with the purpose of better understand the 
problem and find the better way to tag this situation.

So we create a wiki page 
https://wiki.openstreetmap.org/wiki/PoliMappers/mapping_deforestation where is 
possible to discuss these thematics, let us known your idea.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] mapping large memorial objects that roads pass through.

[Graeme Fitzpatrick]

On Thu, 14 Mar 2019 at 10:17, Warin <61sundow...@gmail.com> wrote:

> + 1 on gate way - can be applied to many items.
>
> A node for each pillar and a way to connect them?
>
> Each pillar with man_made=pillar??
> and the way with man_made=gateway???
>

Or draw it as an area? Although if it's only a skinny signboard between the
pillars that may be hard to mark.

Thanks

Graeme
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging