Re: [Tagging] New Tag "Departures" voting results.

[Graeme Fitzpatrick]

On Wed, 13 Mar 2019 at 14:30, Phake Nick  wrote:

> but in term of GTFS I don't think anyone in the world supply data
> individually for each stops.
>

Of course!

It would be nice (but probably impossible) to have a single worldwide
answer but I don't think that will be possible in the foreseeable future :-(

I think it will finish up that we can list this info in this area, people
can do so there, there & there, but people in those other areas
unfortunately won't be able to.

I'd say just go with what we can now, & as areas expand, they can all join
in.

Thanks

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

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

[Mateusz Konieczny]

Mar 13, 2019, 12:33 AM by graemefi...@gmail.com:

> I have no idea how we could improve things so there is more feedback - maybe 
> remove the discussion page from the proposals, so all discussion has to 
> happen on the tagging list?
>
It will rather reduce discussion. People from OSM wiki are more likely to stop 
commenting rather
than start using mailing list. And why commenting on talk page would be worse 
than commenting on ml?

People that participate in mailing list (or Wiki or IRC or forum or slack or 
XYZ) discussions
are extreme outliers of mappers, but given no alternative it is 
OK to assume that their opinion sort represent all OSM mappers.

We are de facto self-elected representative of mappers - it is a really biased 
sample, it 
would be nice to change it but blocking discussion on established site is 
unlikely to help.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Markus]

On Tue, 12 Mar 2019 at 22:44, Graeme Fitzpatrick  wrote:
>
> But oneway=yes is definitely the way to go (sorry, that just slipped out!), 
> rather then clockwise.

I thought that oneway=yes doesn't apply to pedestrians. [1] Thus,
oneway=yes on a highway=path would only apply to cyclists and riders.

If pedestrians are also only allowed to walk in one direction, it
seems you need to add oneway:foot=yes or foot:backward=no.

[1]: https://wiki.openstreetmap.org/wiki/Key:oneway#Interpretation_for_routing

Regards

Markus

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

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

[Martin Koppenhoefer]

sent from a phone

> On 13. Mar 2019, at 01:35, Joseph Eisenberg  
> wrote:
> 
> We considered man_made=gantry (which in general can be used
> for any sort of structure than goes over a road) or man_made=archway.


+1, there is also man_made=arch (32 uses vs 7 for archway)


> 
> There was also a suggestion to tag some of these structures as a type
> of artwork, although this is only sometimes relevant.


+1, add additionally artwork if you consider the thing a work of art.


The section of road itself passing under the arch could be tagged with 
covered=yes, this is a hint for the renderer 


Cheers, Martin 
___
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 13. Mar 2019, at 09:20, Markus  wrote:
> 
> If pedestrians are also only allowed to walk in one direction, it
> seems you need to add oneway:foot=yes or foot:backward=no.


right, this is a typical situation around here: oneway pedestrian roads where 
the oneway applies only to vehicles, on other roads it is also clear that the 
oneway doesn’t apply to pedestrians.

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

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

[Martin Koppenhoefer]

sent from a phone

> On 13. Mar 2019, at 00:33, Graeme Fitzpatrick  wrote:
> 
> Of those 76 active on the list in Nov, 16 people commented on your proposal. 
> When it came to the vote, 33 people voted, but only 2 of them had made 
> comments on the list, but, strangely enough, only 2 people who commented then 
> voted!


if you’re convinced a specific tagging works for you and it doesn’t conflict 
with other schemes (not using the same keys), you can use it (if it uses the 
same keys and is rejected, I would not use it). A negative voting outcome 
doesn’t prevent you necessarily from using the tags, but usually if a proposal 
is rejected there are good reasons to reconsider at least the details.

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

Re: [Tagging] Use of old_name (was Re: Mapping deforestation)

[Marc Gemis]

> > If I decide to meet with a friend AGAIN in front of Whizzo, we both
> > already know where it is.
>
> congratulations if you ever need gps to go to a place where you have
> already been (I wonder in this case why commercial gps have a "go home"
> shortcut since everyone has already been there)
>

totally off-topic:

 I know plenty of people that cannot do that without GPS, including myself.
Can you drive without GPS to any destination that you have visited the
last 20 years? I can't, especially not when I drove there following
the GPS.
For example, I won't be able to drive without a map/GPS to any my
holiday destinations, even not the one from last year. I cannot
remember all the turns we made during a 1000 km trip.

Some people cannot navigate back home from any town center where they
have not been before without using your GPS, especially when there are
a lot of one-way streets, so the trip back is different.

m.

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

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

[Tony Shield]

Been wondering for months how to tag arches in general - not a mention 
in Wiki.


I do like man-made = arch.

I do think that there are several major types of arch which help, so 
this discussion started with torii and a possible answer is given as


Perhaps they could be man_made=archway and archway=torii?

The archway tag could have values such as torii, triumphal-arch (Arc de 
Triomphe in Paris, Marble Arch in London), roman-gate. Suitable values 
for others will be needed.


It seems to me that many arches have a deep cultural significance, often 
they were constructed to be significant in that respect, so I would 
expect memorial or possibly religious tags to be associated with an arch.


How to proceed? If there is agreement does it need voting on? Or can the 
wiki be expanded to show this as a tag?


Regards

TonyS

On 13/03/2019 08:35, Martin Koppenhoefer wrote:


sent from a phone


On 13. Mar 2019, at 01:35, Joseph Eisenberg  wrote:

We considered man_made=gantry (which in general can be used
for any sort of structure than goes over a road) or man_made=archway.


+1, there is also man_made=arch (32 uses vs 7 for archway)



There was also a suggestion to tag some of these structures as a type
of artwork, although this is only sometimes relevant.


+1, add additionally artwork if you consider the thing a work of art.


The section of road itself passing under the arch could be tagged with 
covered=yes, this is a hint for the renderer


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 13. März 2019 00:33:02 MEZ schrieb Graeme Fitzpatrick 
:

>I have no idea how we could improve things so there is more feedback -
>maybe remove the discussion page from the proposals, so all discussion
>has
>to happen on the tagging list?

Or promote proposals better, may by consistently (or even automatically) 
linking them on the wiki pages of the affected tags?

Best, Jan

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

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

[Joseph Eisenberg]

A Torii is not exactly an arch, but it is a gateway (at least
symbolically). Perhaps man_made=gateway is a more general term, which can
incude archways as well as rectangular gateways

If you would like, you can start a proposal page.

On Wed, Mar 13, 2019 at 7:26 PM Tony Shield 
wrote:

> Been wondering for months how to tag arches in general - not a mention
> in Wiki.
>
> I do like man-made = arch.
>
> I do think that there are several major types of arch which help, so
> this discussion started with torii and a possible answer is given as
>
> Perhaps they could be man_made=archway and archway=torii?
>
> The archway tag could have values such as torii, triumphal-arch (Arc de
> Triomphe in Paris, Marble Arch in London), roman-gate. Suitable values
> for others will be needed.
>
> It seems to me that many arches have a deep cultural significance, often
> they were constructed to be significant in that respect, so I would
> expect memorial or possibly religious tags to be associated with an arch.
>
> How to proceed? If there is agreement does it need voting on? Or can the
> wiki be expanded to show this as a tag?
>
> Regards
>
> TonyS
>
> On 13/03/2019 08:35, Martin Koppenhoefer wrote:
> >
> > sent from a phone
> >
> >> On 13. Mar 2019, at 01:35, Joseph Eisenberg 
> wrote:
> >>
> >> We considered man_made=gantry (which in general can be used
> >> for any sort of structure than goes over a road) or man_made=archway.
> >
> > +1, there is also man_made=arch (32 uses vs 7 for archway)
> >
> >
> >> There was also a suggestion to tag some of these structures as a type
> >> of artwork, although this is only sometimes relevant.
> >
> > +1, add additionally artwork if you consider the thing a work of art.
> >
> >
> > The section of road itself passing under the arch could be tagged with
> covered=yes, this is a hint for the renderer
> >
> >
> > 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Hotel dataset import? / Re: Baby-sitting

[Cascafico Giovanni]

>
> Il giorno lun 11 mar 2019 alle ore 14:11 Mateusz Konieczny <
> matkoni...@tutanota.com> ha scritto:
> > Fixed in
> https://wiki.openstreetmap.org/w/index.php?title=Import&diff=1820348&oldid=1551233
>
>
I took a 600+ dataset, geocoded them, manually conflate 53 of them, put
source references on umap, put source institution name on changeset, ask
for some tags clarification (yet didn't receive an agreed feedback).
Am I missing something?

The only (sequential) results of this discussion are:

- I declare <100 nodes but Volker noticed source dataset has 600+, but then:
- I'm asked where the <100 was mentioned (cannot remember), conclusion: I'm
malicious: it's an import!
- since there is one (1) ML unaswered doubt if "01 Jan - 31 Dec" should be
replaced by 24/7: import is anyway bad
- pets and childcare information are "volatile" (payment methods aren't?
and yet tag exists): import is anyway bad
- "bulk" word removed from main import wiki [1]: hence it's obviously an
import

The lattest is great and leads to grotesque consequences: when a colleague
hands me 12 guidepost locations to geocode, I must message planet import
ML, local ML, write an import page and ask my fellow a consent form with
certified signature. Is this what we aim?
I think setting such a binding requirements on small size "imports" is
putting a gravestone on many potential small, local sources.

Please, forgive my sarcasm, but I'm really discouraged. I published the 53
changeset id's [2]. Feel free to revert.
If anybody wants to help me, please feed back on the import doc I wrote
on-the-fly [3]

[1]
https://wiki.openstreetmap.org/w/index.php?title=Import&type=revision&diff=1820348&oldid=1551233
[2] https://ethercalc.org/hpil8syy4rgz.csv
[3] https://wiki.openstreetmap.org/wiki/Import/Catalogue/Hotels-RAFVG-umap
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Hotel dataset import? / Re: Baby-sitting

[Tom Pfeifer]

On 13.03.2019 10:50, Cascafico Giovanni wrote:

The lattest is great and leads to grotesque consequences: when a colleague hands me 12 guidepost 
locations to geocode, I must message planet import ML, local ML, write an import page and ask my 
fellow a consent form with certified signature. Is this what we aim?
I think setting such a binding requirements on small size "imports" is putting a gravestone on many 
potential small, local sources.


I think you misunderstand. OSM is based on locally sourced, handcrafted data. That creates the high 
quality.


Import means data are copied from another database into OSM. That means, somebody else collected the 
data. This collector has made his own mistakes. All databases contain errors, or outdated items, 
even if they are labelled official, governmental etc.


IIRC the dataset you are using is several years old, last updated 2017. The items in your Umap do 
not say when the database entry was last checked.


Thus when copying these data into OSM, they appear as freshly updated, March 2019, although the 
information is much older and the hotel might have closed or changed ownership/pet policies/wifi in 
2018. In particular in a "stealth" import, one node at a time, I would assume the OSM data to be 
individually checked and current.


Thus your task is to discuss with the Italian community if your import, i.e. copying the other data, 
improves or decreases the OSM data quality. The changeset size is less important, though I would 
prefer an community-approved import to be traceable in not too many changesets.


Your colleagues data of 12 guideposts are fine if they are freshly collected 
from the ground.

Hope that helps to understand why we are careful with imports.

tom

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

Re: [Tagging] Hotel dataset import? / Re: Baby-sitting

[marc marc]

Hello,

Le 13.03.19 à 10:50, Cascafico Giovanni a écrit :
> - since there is one (1) ML unaswered doubt if "01 Jan - 31 Dec" should 
> be replaced by 24/7: import is anyway bad

I find that they are 2 totally different things: one informs that the 
poi is open all year round, the other all day. for the majority of poi, 
you can't deduct from each other (a gas station can be open all year 
round but only from 8:00 am to 8:00 pm because located for example
in a shopping centre that closes access during the night.)

> - pets and childcare information are "volatile" (payment methods aren't? 
> and yet tag exists): import is anyway bad

from what I see, a common cause of import failure is when the proposer 
refuses to take into account the local community concerned. if the 
latter considers that the information of pets dating from 2 years ago is 
too volatile, the best way to achieve failure is to persist in wanting 
to import them with everything else. the best way to progress is to 
propose a first step without this data (split out data that provoke 
criticism), it is always possible to propose an addition (divide
to avoid "all or nothing").

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

Re: [Tagging] Hotel dataset import? / Re: Baby-sitting

[Sergio Manzi]

On 2019-03-13 12:15, Tom Pfeifer wrote:
> I think you misunderstand. OSM is based on locally sourced, handcrafted data. 
> That creates the high quality.

That's totally inaccurate.

The reality is that OSM is based on imported data, augmented by locally sourced 
information (/of ///sometimes /questionable quality/).

Sergio



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New Tag "Departures" voting results.

[Phake Nick]

maybe we can use some keys like eta_link:shortnameofbuscompanyA=*
and eta_link:shortnameofbuscompanyB=* to show different operators
information

在 2019年3月13日週三 15:01，Graeme Fitzpatrick  寫道：

>
>
> On Wed, 13 Mar 2019 at 14:30, Phake Nick  wrote:
>
>> but in term of GTFS I don't think anyone in the world supply data
>> individually for each stops.
>>
>
> Of course!
>
> It would be nice (but probably impossible) to have a single worldwide
> answer but I don't think that will be possible in the foreseeable future :-(
>
> I think it will finish up that we can list this info in this area, people
> can do so there, there & there, but people in those other areas
> unfortunately won't be able to.
>
> I'd say just go with what we can now, & as areas expand, they can all join
> in.
>
> Thanks
>
> Graeme
> ___
> 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] Superroutes - good, bad or ugly?

[Paul Allen]

I've hesitated to ask this question for months now: what's the
consensus on superroutes?  Going by all I can find on the wiki,
forums and past discussions, they're highly controversial.  One wiki
page mentions them and says don't use them.  They were either
never well documented on the wiki or some documentation has
been scrubbed.  What I don't know is whether the intense dislike
some people expressed when they were first proposed has faded
or if they're still largely considered to be a very bad idea.

One justification for them is that they simplify the mapping of
trans-national routes or very long routes: individual sections can
be mapped separately and then assembled into a coherent whole
as a superroute.

Another justification is that very long ways (the figure I've seen is
300 nodes) can be problematic and they should be split into
a superroute of individual routes.

An argument against them is that some routers may not be able
to handle them.  Which would obviously have been true when they
were first proposed and may still be true now.  Which is a problem
with just about everything proposed here: we propose something
new, it's argued against because editors/renderers/routers don't
handle it, but the reason editors/renderers/routers don't handle it
is because nobody uses it.

The reason I ask is that I can see an application for them that is
not explicitly mentioned in the documentation but might allow me
to deal with an otherwise intractable problem.  If there is universal
disdain here I'll have to abandon that idea.  But if there are enough
people who are happy with them then I have some questions...

Please don't let this degenerate into a flame war.  That can come when
(if) I explain what I want to do with a superroute - even the people who
support superroutes (if there are any) may be unhappy with that idea.

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

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

[Andy Townsend]

On 13/03/2019 13:18, Paul Allen wrote:

I've hesitated to ask this question for months now: what's the
consensus on superroutes?


In what context are you asking the question?  I can think of examples 
where the answer would be "a really bad idea" and others where the 
answer would be "essential; there's really no other sensible way to have 
that data in OSM".


Best Regards,

Andy



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

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

[Sergio Manzi]

If a "/superroute/" has an official status (/like this one: 
https://www.openstreetmap.org/relation/20773/), I'm all-in for that.

If instead it is something "/invented/" by the mapper, than I'm all-against it.

Can you please provide more information/examples/context?

Sergio


On 2019-03-13 14:18, Paul Allen wrote:
> I've hesitated to ask this question for months now: what's the
> consensus on superroutes?  Going by all I can find on the wiki,
> forums and past discussions, they're highly controversial.  One wiki
> page mentions them and says don't use them.  They were either
> never well documented on the wiki or some documentation has
> been scrubbed.  What I don't know is whether the intense dislike
> some people expressed when they were first proposed has faded
> or if they're still largely considered to be a very bad idea.
>
> One justification for them is that they simplify the mapping of
> trans-national routes or very long routes: individual sections can
> be mapped separately and then assembled into a coherent whole
> as a superroute.
>
> Another justification is that very long ways (the figure I've seen is
> 300 nodes) can be problematic and they should be split into
> a superroute of individual routes.
>
> An argument against them is that some routers may not be able
> to handle them.  Which would obviously have been true when they
> were first proposed and may still be true now.  Which is a problem
> with just about everything proposed here: we propose something
> new, it's argued against because editors/renderers/routers don't
> handle it, but the reason editors/renderers/routers don't handle it
> is because nobody uses it.
>
> The reason I ask is that I can see an application for them that is
> not explicitly mentioned in the documentation but might allow me
> to deal with an otherwise intractable problem.  If there is universal
> disdain here I'll have to abandon that idea.  But if there are enough
> people who are happy with them then I have some questions...
>
> Please don't let this degenerate into a flame war.  That can come when
> (if) I explain what I want to do with a superroute - even the people who
> support superroutes (if there are any) may be unhappy with that idea.
>
> -- 
> Paul
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Hotel dataset import? / Re: Baby-sitting

[Cascafico Giovanni]

> Il giorno mer 13 mar 2019 alle ore 12:16 Tom Pfeifer <
t.pfei...@computer.org> ha scritto:

> I think you misunderstand. OSM is based on locally sourced, handcrafted
data. That creates the high quality

Have youi ever seen hot tasks results? Huge building polys, mixed
misalignments, nonxistent tags... lots of poor quality stuff and, worst of
all, everything mixed to (few) high quality surveys... but it seems they
are useful...of course they are: later you can improve them.

> Import means data are copied from another database into OSM. That means,
somebody else collected the data. This collector has made his own mistakes.
All databases contain errors, or outdated items, even if they are labelled
official, governmental etc.

The collector, whoever he is, is not error free (he is human). OSM mappers
are humans.

The 53 POIs were not simply copied: they were geocoded, (possibly, tag
mapped (if this ML gather some verdicts), location checked, conflated. If
you write "Import means data are copied from another database into OSM",
you are saying mine is not an import. Hence I think we lack a proper,
better import definition, rather then the extremely generic version updated
yesterday.

> IIRC the dataset you are using is several years old, last updated 2017.
The items in your Umap do
> not say when the database entry was last checked.
> Thus when copying these data into OSM, they appear as freshly updated,
March 2019, although the
> information is much older and the hotel might have closed or changed
ownership/pet policies/wifi in
> 2018.

Again, "freshly" word is subjectiive. Is a 2 y/o address "fresh"? Is a 3 mo
old payment method "fresh"?Probably you are right, there could be some
hotel diisused, less likely dismantled, several may have canceled visa
payments,,,but I think that no data in worse.

In sept 2015, in the same region, an import was performed involving >400k
address nodes. Same hotel source, same method: dataset built collecting
gathered municipality surveys; data published in may 2014, survey dates
unknown. Until today nobody complained about that import, even if some
addresses were void, even if some we discovered be replaced. AFAIK those
addresses are anyway in use and are a good base for geocoding: should we
had abort that import?

> Thus your task is to discuss with the Italian community if your import,
i.e. copying the other data,
> improves or decreases the OSM data quality. The changeset size is less
important, though I would
> prefer an community-approved import to be traceable in not too many
changesets.

Due to the nature of the umap editing, this "import" couldn't be performed
in one shot. neither uploaded by a dedicated account. What I was aiming,
when I started asking suggestions n this ML, was to set a tagging plan for
a commnity based, umap supported "import". If this doesn't fit anymore the
official import definition, let's forget about it.

Sincerely, thank for your feedback.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Martin Koppenhoefer]

Am Mi., 13. März 2019 um 14:31 Uhr schrieb Sergio Manzi :

> If a "*superroute*" has an official status (*like this one:
> https://www.openstreetmap.org/relation/20773
> *), I'm all-in for that.
>
> If instead it is something "*invented*" by the mapper, than I'm
> all-against it.
>
> Can you please provide more information/examples/context?
>


there are really long relations (e.g. Via Francigena / St. Francis Way, or
European E-Routes, which cross half of Europe). Splitting them into smaller
pieces helps reducing editing conflicts (2 people editing the same object
at the same time). This is often done along administrative boundaries
(regional, national).

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

Re: [Tagging] Hotel dataset import? / Re: Baby-sitting

[Martin Koppenhoefer]

Am Mi., 13. März 2019 um 12:54 Uhr schrieb Sergio Manzi :

> On 2019-03-13 12:15, Tom Pfeifer wrote:
>
> I think you misunderstand. OSM is based on locally sourced, handcrafted
> data. That creates the high quality.
>
> That's totally inaccurate.
>
> The reality is that OSM is based on imported data, augmented by locally
> sourced information (*of **sometimes questionable quality*).
>


There are examples for this like the US, Friuli Venezia Giulia (buildings),
maybe France (landcover + cadastre) and the Netherlands, but this is still
not globally the case, and I would hope it will not get to this point. You
are relatively new here Sergio and may not know the history of OSM, also in
Italy where you map, most data was mapped by mappers. Notable Italian
exceptions may be Friuli Venezia Giulia, administrative boundaries by
ISTAT, fuel station import last year, some locally confined imports in some
municipalities.

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

Re: [Tagging] Hotel dataset import? / Re: Baby-sitting

[Andy Townsend]

On 13/03/2019 13:34, Cascafico Giovanni wrote:


Have you ever seen hot tasks results? Huge building polys, mixed 
misalignments, nonxistent tags... lots of poor quality stuff and, 
worst of all, everything mixed to (few) high quality surveys... but it 
seems they are useful...of course they are: later you can improve them.


Just because someone else makes a pigs ear of adding data to OSM doesn't 
mean you should too :)


This sort of thing has been a problem in OSM for a _very_ long time. 
https://blog.gravitystorm.co.uk/2009/11/10/the-pottery-club/ was written 
nearly 10 years ago now!


Best Regards,

Andy



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

Re: [Tagging] Hotel dataset import? / Re: Baby-sitting

[Martin Koppenhoefer]

Am Mi., 13. März 2019 um 14:36 Uhr schrieb Cascafico Giovanni <
cascaf...@gmail.com>:

> > Il giorno mer 13 mar 2019 alle ore 12:16 Tom Pfeifer <
> t.pfei...@computer.org> ha scritto:
>
> > I think you misunderstand. OSM is based on locally sourced, handcrafted
> data. That creates the high quality
>
> Have youi ever seen hot tasks results? Huge building polys, mixed
> misalignments, nonxistent tags... lots of poor quality stuff and, worst of
> all, everything mixed to (few) high quality surveys... but it seems they
> are useful...of course they are: later you can improve them.
>


if you see issues in other fields, you should raise them (in the end, HOT
tasks aren't imports though, so they follow different requirements). They
cannot be used to justify importing other data.




>
> > Import means data are copied from another database into OSM. That means,
> somebody else collected the data. This collector has made his own mistakes.
> All databases contain errors, or outdated items, even if they are labelled
> official, governmental etc.
>
> The collector, whoever he is, is not error free (he is human). OSM mappers
> are humans.
>


yes, but we have our own type of error, and we have personal responsability
for the things we are entering.

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

Re: [Tagging] Hotel dataset import? / Re: Baby-sitting

[Sergio Manzi]

On 2019-03-13 14:45, Martin Koppenhoefer wrote:
>
> Am Mi., 13. März 2019 um 12:54 Uhr schrieb Sergio Manzi  >:
>
> On 2019-03-13 12:15, Tom Pfeifer wrote:
>> I think you misunderstand. OSM is based on locally sourced, handcrafted 
>> data. That creates the high quality.
>
> That's totally inaccurate.
>
> The reality is that OSM is based on imported data, augmented by locally 
> sourced information (/of ///sometimes /questionable quality/).
>
>
>
> There are examples for this like the US, Friuli Venezia Giulia (buildings), 
> maybe France (landcover + cadastre) and the Netherlands, but this is still 
> not globally the case, and I would hope it will not get to this point. You 
> are relatively new here Sergio and may not know the history of OSM, also in 
> Italy where you map, most data was mapped by mappers. Notable Italian 
> exceptions may be Friuli Venezia Giulia, administrative boundaries by ISTAT, 
> fuel station import last year, some locally confined imports in some 
> municipalities.
>
> Cheers,
> Martin
>
Was this https://www.openstreetmap.org/node/288179924 mapped by Reinhold 
Messner carrying an high accuracy GPS in is backback? As I think he is one of 
the very few who put foot there...

Sergio



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[David Marchal]

Hello, there.

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?

Awaiting your answers,

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

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

[Paul Allen]

On Wed, 13 Mar 2019 at 13:29, Andy Townsend  wrote:

> On 13/03/2019 13:18, Paul Allen wrote:
> > I've hesitated to ask this question for months now: what's the
> > consensus on superroutes?
>
> In what context are you asking the question?  I can think of examples
> where the answer would be "a really bad idea" and others where the
> answer would be "essential; there's really no other sensible way to have
> that data in OSM".
>

That's more positive than I expected: they're not always on a par with
eating babies but the use
has to be justifiable.

Can I get the data into OSM without a superroute?  Sure.  Is that data
useful without a superroute?
Not so much.  It is this bus route:
https://www.openstreetmap.org/relation/8592409#map=14/52.0860/-4.6644
That is incomplete and has some omissions and errors.  I really ought to
fix it, but I had
this thought about superroutes and realized if I fixed and then found out I
could use a
superroute I'd later have to rework a few things.

It's a circular.  It starts at what can loosely be called the bus station.
It does what can loosely
be called a hairy circular route to return to the bus station.  The route
then continues on a side
trip and eventually returns to the bus station, completing the "circle."

There are places where the bus goes into a dead-end and gets out by
reversing into a side
junction.  This differs from similar manoeuvres at a terminus of a
non-circular route because
passengers are on board.  It does a loop-the-loop.  It appears to do a
figure-8 but actually
there are other side-trips that mean it really isn't.

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).

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.

Splitting it into route segments would also make it clearer what happens in
the loop-the-loop
and the figure-of-8 in the town centre, if the splits are chosen
judiciously.  If I'm really clever
I can find splits that make the variant routes fit in nicely, too.  You
think that route is insane?
Wait until I add the variants.

Best of all, I could pull these into umap.  It would then be possible to
display route segments
in turn to see where the bus goes rather than trying to puzzle it out from
the overall route.  Yes,
if you're very familiar with OSM you can puzzle it out from the relation,
but most people can't do
that (and I find it difficult, even with knowledge of how the route runs).

So, good idea, bad idea, or should I stick to eating babies as that would
be more socially
acceptable?

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

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

[marc marc]

Le 13.03.19 à 14:59, David Marchal a écrit :
> the JOSM validator claims that contiguous outer members is an error

yes it's- the sum of all outer should not have a "internal" way
like this one 
https://www.openstreetmap.org/relation/9393253#map=17/48.42219/5.92713
so draw a new way for the outer of this part
or split currents ways to include only the outer part in the relation
and make another relation for the leaf_type


> openstreetmap.org renders a misplaced name

It doesn't seem so misplaced
https://www.openstreetmap.org/#map=15/48.4222/5.9197
but that's not due to the tag

> no leaf_type

it's hard to render a forêt with several leaf_type
you may put natural=wood landcover=trees to every part of the forêt 
having a different leaf_type
but you 'll have a duplicate forest : a foret at the relatin level and 
at every part. currently i'm not aware of a good schema to avoid this 
(you can trick some QA tools by using landuse=forest for the 
relationship and natural=wook for all parts, but see the wiki for 
forest, the meaning of these 2 tags is random/variable depending on the 
mapper, the only meaning you can get is "there are trees", the same 
meaning for the 2 tag)

Regards,
Marc

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

Re: [Tagging] Hotel dataset import? / Re: Baby-sitting

[Mateusz Konieczny]

Mar 13, 2019, 12:53 PM by s...@smz.it:

> On 2019-03-13 12:15, Tom Pfeifer wrote:
>
>> I  think you misunderstand. OSM is based on locally sourced,  
>> handcrafted data. That creates the high quality. 
>>
>
> That's totally inaccurate.
>
>
> The reality is that OSM is based on imported data, augmented by  locally 
> sourced information (> of > sometimes > questionablequality> ).
>
>
> Sergio
>
>
[citation needed]

It may be true in some rare regions, in many cases real mapping requires 
deletion of substandard
imports dumped into OSM (see TIGER mess in USA, low quality landcover in 
Slovakia making 
mapping a horrible experience).

Describing OSM as "imported data, augmented by" is as far as I known complete 
misrepresenting the
situation.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Hotel dataset import? / Re: Baby-sitting

[Volker Schmidt]

Just my five €cents:
My experience with the massive imports in Veneto is, under many aspects,
negative.
I have tried in vain to stop or revert them.
There are a number of problems, just to list a few basic ones:

   - we import perisahbale data which are at best remotely related to what
   should be in a geographical database
   - we are importing data without verifyiing them
   - we do not have the manpower to maintain imported data
   - and the most basic one is that data imports are in 100% contrast with
   the basic database rule of keeping and updating data only in one place.
   Importing perishable data from other sources into OSM is simply wrong.
   External data should be linked, but never copied.


On Wed, 13 Mar 2019 at 14:59, Sergio Manzi  wrote:

> On 2019-03-13 14:45, Martin Koppenhoefer wrote:
>
>
> Am Mi., 13. März 2019 um 12:54 Uhr schrieb Sergio Manzi :
>
>> On 2019-03-13 12:15, Tom Pfeifer wrote:
>>
>> I think you misunderstand. OSM is based on locally sourced, handcrafted
>> data. That creates the high quality.
>>
>> That's totally inaccurate.
>>
>> The reality is that OSM is based on imported data, augmented by locally
>> sourced information (*of **sometimes questionable quality*).
>>
>
>
> There are examples for this like the US, Friuli Venezia Giulia
> (buildings), maybe France (landcover + cadastre) and the Netherlands, but
> this is still not globally the case, and I would hope it will not get to
> this point. You are relatively new here Sergio and may not know the history
> of OSM, also in Italy where you map, most data was mapped by mappers.
> Notable Italian exceptions may be Friuli Venezia Giulia, administrative
> boundaries by ISTAT, fuel station import last year, some locally confined
> imports in some municipalities.
>
> Cheers,
> Martin
>
> Was this https://www.openstreetmap.org/node/288179924 mapped by Reinhold
> Messner carrying an high accuracy GPS in is backback? As I think he is one
> of the very few who put foot there...
>
> Sergio
> ___
> 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] Hotel dataset import? / Re: Baby-sitting

[Mateusz Konieczny]

Mar 13, 2019, 2:34 PM by cascaf...@gmail.com:

> > Il giorno mer 13 mar 2019 alle ore 12:16 Tom Pfeifer <> 
> > t.pfei...@computer.org > > ha scritto:
>
> > I think you misunderstand. OSM is based on locally sourced, handcrafted 
> > data. That creates the high quality
> Have youi ever seen hot tasks results? Huge building polys, mixed 
> misalignments, nonxistent tags... lots of poor quality stuff and, worst of 
> all, everything mixed to (few) high quality surveys... but it seems they are 
> useful...of course they are: later you can improve them.
> > Import means data are copied from another database into OSM. That means, 
> > somebody else collected the data. This collector has made his own mistakes. 
> > All databases contain errors, or outdated items, even if they are labelled 
> > official, governmental etc.
>
Extremely low quality of HOT mapping (in part, maybe mostly remote mapping, not 
local surveys)
is other big problem and I would not lump HOT organized mapping with local 
mappers.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Hotel dataset import? / Re: Baby-sitting

[Sergio Manzi]

On 2019-03-13 15:27, Mateusz Konieczny wrote:
>
>
>
> Mar 13, 2019, 12:53 PM by s...@smz.it:
>
> On 2019-03-13 12:15, Tom Pfeifer wrote:
>> I think you misunderstand. OSM is based on locally sourced, handcrafted 
>> data. That creates the high quality.
>
> That's totally inaccurate.
>
> The reality is that OSM is based on imported data, augmented by locally 
> sourced information (/of ///sometimes /questionable quality/).
>
> Sergio
>
> [citation needed]
>
> It may be true in some rare regions, in many cases real mapping requires 
> deletion of substandard
> imports dumped into OSM (see TIGER mess in USA, low quality landcover in 
> Slovakia making
> mapping a horrible experience).
>
> Describing OSM as "imported data, augmented by" is as far as I known complete 
> misrepresenting the
> situation.

I haven't said that OSM *is* imported data, but that it is *based on* imported 
data: that's different. And I never said that the "augmentation" contributed by 
mappers is of irrelevant importance (/even if sometime the quality is sub-par/).

Have mappers walked along the whole world coastlines? Have they descended all 
world's rivers by canoe? Have all Mumbay, New York, Rome, Shanghai, etc., 
streets and alleys been walked by volunteers mapping their location and names? 
All the peaks escalated?

Sergio




smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Peter Elderson]

I can't answer the question for busrelations.

For long hiking routes and walking node networks, relations containing
relations are very important.

Without those, maintenance of long hiking routes becomes a p.i.t.b,
sometimes near impossible.

Rendering can be done without superroutes, just by rendering each piece
separately. But datausers need to resolve the hierarchy. Waymarkedtrails
does that nicely for long recreational routes: Just replace every member
relation with its content, recursively. Works nicely- if it's only ways in
the lowest level relations.

I'm not sure if your case needs just rendering or also data
use/routing/navigation.

Vr gr Peter Elderson


Op wo 13 mrt. 2019 om 15:05 schreef Paul Allen :

> On Wed, 13 Mar 2019 at 13:29, Andy Townsend  wrote:
>
>> On 13/03/2019 13:18, Paul Allen wrote:
>> > I've hesitated to ask this question for months now: what's the
>> > consensus on superroutes?
>>
>> In what context are you asking the question?  I can think of examples
>> where the answer would be "a really bad idea" and others where the
>> answer would be "essential; there's really no other sensible way to have
>> that data in OSM".
>>
>
> That's more positive than I expected: they're not always on a par with
> eating babies but the use
> has to be justifiable.
>
> Can I get the data into OSM without a superroute?  Sure.  Is that data
> useful without a superroute?
> Not so much.  It is this bus route:
> https://www.openstreetmap.org/relation/8592409#map=14/52.0860/-4.6644
> That is incomplete and has some omissions and errors.  I really ought to
> fix it, but I had
> this thought about superroutes and realized if I fixed and then found out
> I could use a
> superroute I'd later have to rework a few things.
>
> It's a circular.  It starts at what can loosely be called the bus
> station.  It does what can loosely
> be called a hairy circular route to return to the bus station.  The route
> then continues on a side
> trip and eventually returns to the bus station, completing the "circle."
>
> There are places where the bus goes into a dead-end and gets out by
> reversing into a side
> junction.  This differs from similar manoeuvres at a terminus of a
> non-circular route because
> passengers are on board.  It does a loop-the-loop.  It appears to do a
> figure-8 but actually
> there are other side-trips that mean it really isn't.
>
> 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).
>
> 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.
>
> Splitting it into route segments would also make it clearer what happens
> in the loop-the-loop
> and the figure-of-8 in the town centre, if the splits are chosen
> judiciously.  If I'm really clever
> I can find splits that make the variant routes fit in nicely, too.  You
> think that route is insane?
> Wait until I add the variants.
>
> Best of all, I could pull these into umap.  It would then be possible to
> display route segments
> in turn to see where the bus goes rather than trying to puzzle it out from
> the overall route.  Yes,
> if you're very familiar with OSM you can puzzle it out from the relation,
> but most people can't do
> that (and I find it difficult, even with knowledge of how the route runs).
>
> So, good idea, bad idea, or should I stick to eating babies as that would
> be more socially
> acceptable?
>
> --
> 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] Hotel dataset import? / Re: Baby-sitting

[Sergio Manzi]

On 2019-03-13 15:44, Sergio Manzi wrote:
> On 2019-03-13 15:27, Mateusz Konieczny wrote:
>>
>>
>>
>> Mar 13, 2019, 12:53 PM by s...@smz.it:
>>
>> On 2019-03-13 12:15, Tom Pfeifer wrote:
>>> I think you misunderstand. OSM is based on locally sourced, handcrafted 
>>> data. That creates the high quality.
>>
>> That's totally inaccurate.
>>
>> The reality is that OSM is based on imported data, augmented by locally 
>> sourced information (/of ///sometimes /questionable quality/).
>>
>> Sergio
>>
>> [citation needed]
>>
>> It may be true in some rare regions, in many cases real mapping requires 
>> deletion of substandard
>> imports dumped into OSM (see TIGER mess in USA, low quality landcover in 
>> Slovakia making
>> mapping a horrible experience).
>>
>> Describing OSM as "imported data, augmented by" is as far as I known 
>> complete misrepresenting the
>> situation.
>
> I haven't said that OSM *is* imported data, but that it is *based on* 
> imported data: that's different. And I never said that the "augmentation" 
> contributed by mappers is of irrelevant importance (/even if sometime the 
> quality is sub-par/).
>
> Have mappers walked along the whole world coastlines? Have they descended all 
> world's rivers by canoe? Have all Mumbay, New York, Rome, Shanghai, etc., 
> streets and alleys been walked by volunteers mapping their location and 
> names? All the peaks escalated?
>
> Sergio
>
... an example of massively imported data (/which I agree with, btw.../): 
https://blogs.bing.com/maps/2018-06/microsoft-releases-125-million-building-footprints-in-the-us-as-open-data



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[s8evq]

> 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)

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?

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

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

[Paul Allen]

On Wed, 13 Mar 2019 at 15:38, s8evq  wrote:

>
> 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?
>

Because somebody put it there.

Oh, you wanted the ultimate cause not the proximate cause.  The thing about
the wiki is that
"because somebody put it there" may actually be the ultimate cause.
Something may appear
in the wiki for no reason other than the voices in somebody's head told
that person to put it
there.

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

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

[Kevin Kenny]

On Wed, Mar 13, 2019 at 11:47 AM Paul Allen  wrote:
> Something may appear
> in the wiki for no reason other than the voices in somebody's head told that 
> person to put it
> there.

Moreover, because we as a community usually try to respect the work of
other mappers (as much as we bicker on this list), these things tend
to persist on the Wiki because nobody really wants to take the
confrontational act of silencing the voices in someone else's head.

And you're just envious because the voices won't talk to you!

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

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

[Kevin Kenny]

On Wed, Mar 13, 2019 at 11:03 AM Peter Elderson  wrote:
> I can't answer the question for busrelations.
(neither can I)

> For long hiking routes and walking node networks, relations containing 
> relations are very important.
> Without those, maintenance of long hiking routes becomes a p.i.t.b, sometimes 
> near impossible.

Exactly. What is 'long' kind of varies. When I mapped
https://www.openstreetmap.org/relation/4286650, I used a single
relation, because there were relatively few member ways and very few
natural points to break it into pieces.

For the work in progress,
https://www.openstreetmap.org/relation/919642, I found that trying to
maintain a single relation was totally unmanageable. In fact, I
tripped over a bug (since fixed) in JOSM with handling a relation that
big, and had to switch to Meerkartor while breaking it up. I decided
that the most natural break was on county lines, although I didn't
trouble with separating off the tiny segment that is on the streets of
Manhattan (New York County). That worked out well, and Waymarked
Trails is happy with it. (The remaining gaps have nothing to do with
tagging. I simply haven't mapped them yet, and won't until the weather
improves. I dislike mapping on snowshoes, because too often I discover
that the snowshoe track doesn't follow the actual treadway.)

> Rendering can be done without superroutes, just by rendering each piece 
> separately. But datausers need to resolve the hierarchy. Waymarkedtrails does 
> that nicely for long recreational routes: Just replace every member relation 
> with its content, recursively. Works nicely- if it's only ways in the lowest 
> level relations.

Most renderers and routers work that way, because that's how osm2pgsql
works. In fact, there is no non-deprecated way to access relation
information at the time of routing or rendering, if you use osm2pgsql;
all relations have been reduced to single ways and/or multipolygons.
(That's why I'm planning to investigate using imposm3 for my own
experimental stuff on route concurrences - I find myself needing the
route relations after osm2pgsql has thrown them away.)

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

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

[Paul Allen]

On Wed, 13 Mar 2019 at 16:27, Kevin Kenny  wrote:

>
> And you're just envious because the voices won't talk to you!
>

I really hate it when people can figure out my inner motivations.

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

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

[Hufkratzer]

On 12.03.2019 12:30, s8evq qrote:
> [...] I see there is also the tag "direction=" with a lot more usage. 
On mini-roundabouts (as documented in the wiki 
https://wiki.openstreetmap.org/wiki/Key:direction#Clockwise_and_anticlockwise), 
but sometimes even on route=foot, route=hiking and route=bicycle (not 
documented in the wiki) [...]


direction=* would be applicable in some cases where oneway=cw/ccw is 
not. Example:

https://www.openstreetmap.org/relation/4496757#map=13/50.0507/8.8246


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

Re: [Tagging] Feature proposal - RFC - Line attachments

[François Lacombe]

Hi Sergio,

Thank you for feedbacks, my answers below.

One general reminder:
I'm not the one who start to map nor line attachments, nor substations
shared between pipelines and power lines.
tower:type=anchor, tower:type=suspension and pipeline=substation were
already widely used and reviewed.
Tagging should be improved for the sake of benefits listed in proposed
documents

Le mer. 13 mars 2019 à 01:21, Sergio Manzi  a écrit :

> So, your updated picture made it clear that it is the "insulator set" what
> should be mapped with your newly proposed tag. I suppose  that for power
> lines the same would be true in case the "line attachment" would be through
> a "pin insulator" or a "shackle insulator" or every other form of insulator.
>
In case of power line, the insulator set (chains + linking accessories) AND
clamps.
Yes it may be the same for other values which I can provide similar pictures

> So, when one is supposed to use the "power=insulator" tag instead?
>
> The wiki for that tag (*which you wrote*) is describing insulators as "*Power
> insulator linking a power line to a support*" and also "*It's a power
> insulator linking an overhead line to another (grounded) infrastructure*".
>
> In the examples there is also a picture of a concrete portal with the
> caption stating: "*Support : Insulators are used to anchor the power line
> on a concrete portal*".
>
When the support is mapped as a separate object. For instance a portal
mapped as a way. The shared node between the portal and the line gets
power=insulator + proposed line_attachment.
https://wiki.openstreetmap.org/wiki/File:Portal_portal_as_way.png

> *So we should tag the same node as both a "power=insulator" and
> "line_attachment=suspension", or should we map a distinct node for the
> "line_attachment"?*
>
When power=insulator is applicable, the same node can get a line_attachment
tag also. There is not always an insulator involved with line attachment.

In case of a tower mapped as a node (most of them), we can't mix
power=tower and power=insulator on the same object.

> I would barely understand if you only had *two values* for
> line_attachment *as properties of the "insulator" key*: suspension and
> anchor, distinguishing if the vector of forces on an insulator add-up to an
> essentially vertical vector because the "traction" forces of two catenaries
> compensate each other and you just have a vertical component of force at
> the binding post (*suspension*), or you don't have the compensation of
> the two catenaries (the line is attached to a fixed post or the two
> catenaries are not compensated) and you also have an horizontal component
> of force that the binding post must sustain (*anchor*). Not much useful
> to know, IMHO,  but hey, who am I to judge that?
>
> But that's not the case, unhappily! In your proposal you also describe 
> "*shackle
> insulators*" and "*pin insulators*" as "line attachments". For me they
> should have been documented in the "insulator" key as types of insulators 
> (*yes,
> Warin, I know you dislike "type" and it goes under your skin...*).
>
As Warin, I also dislike the type tags.
Lines aren't always attached with insulators, unfortunately.
Previous discussions shows that pin attachment isn't equivalent to
suspension one and I already adapted the document for that as I remember.
Shackle insulators and pin insulators are particular situations for shackle
and pin attachments. I should provide more example without insulators for
that.
To me this is also shackle attachment :
http://aac-publications.s3.amazonaws.com/anam-13201213050-1424994510.png

> *A**s I wrote you in our personal mail exchange I have the feeling that
> you are trying to map "concepts", not "things", through generalization: the
> Platonic idea of a line attachment in this case.*
>
> You're doing the same in your current proposal about "substations" 
> (*https://wiki.openstreetmap.org/wiki/Proposed_features/Substation_functions
> *),
> where you want to generalize the concept of "substation" and apply it to
> both the domain of power distribution (power) and fluid distributions
> (pipeline).
>
> That's profoundly wrong in my opinion and I strongly feel that this should
> stop: we are not here "to put order in the universe" and categorize a and
> "name things" (*I'm an atheist, so I'm not much informed about this
> things, but I seems to remember that the Bible talks about that...*), we
> are here to map useful information about things.
>
Could you elaborate on why is this wrong please?
I agree on concepts vs things (while I consider things as a particular kind
of concepts) but the point isn't to put order in the universe, just share
concepts and reuse established works.
OSM is also known through this.

All the best

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

Re: [Tagging] Hotel dataset import? / Re: Baby-sitting

[Volker Schmidt]

On Wed, 13 Mar 2019 at 15:45, Sergio Manzi  wrote:

> Have mappers walked along the whole world coastlines? Have they descended
> all world's rivers by canoe?
>
No, these are examples where imports make sense as these are feature that
change slowly (normally)

Have all Mumbay, New York, Rome, Shanghai, etc., streets and alleys been
> walked by volunteers mapping their location and names?
>
No, but many have been photographed and the photographs are available with
open license (Mapillary and OpenStreetCam) and many raods have been
recorded with GPX tracks. This allows armchair mapping with high quality
results, where the mapper does not need to be the photographer.
New York on OpenStreetCam
,
Amsterdam
on Mapillary


All the peaks escalated?
>
Again classical data that change slowly, where imports are justified.

But when you start importing trees or buildings or hotels or petrol
stations or shops or crops than you are importing  perishable data which
are maintained outside OSM, and hence need frequent updates, with the
obvious cost that they need to be updated in the external source database
and in the OSM database in synchronism.

Volker

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

[Tagging] Expand the key:opening_hours

[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. See 
https://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 07:00 is referring to
07:00 on the next day.

Any thought on the proposal?

___
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 13. Mar 2019, at 16:37, s8evq  wrote:
> 
> 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


then it is clear that neither oneway nor oneway:foot apply (both are legal 
prescriptions and not just recommendations).

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

Re: [Tagging] Hotel dataset import? / Re: Baby-sitting

[Martin Koppenhoefer]

sent from a phone

> On 13. Mar 2019, at 15:44, Sergio Manzi  wrote:
> 
> Have mappers walked along the whole world coastlines? Have they descended all 
> world's rivers by canoe? Have all Mumbay, New York, Rome, Shanghai, etc., 
> streets and alleys been walked by volunteers mapping their location and 
> names? All the peaks escalated?


I don’t know about New York or Shanghai, but in Rome the mappers have indeed 
walked the streets, usually multiple times since 2004. Definitely not based on 
imported data. Neither are rivers or the coastline, these features are derived 
from aerial imagery (not an import).

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

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

[Kevin Kenny]

On Wed, Mar 13, 2019 at 3:04 PM Martin Koppenhoefer
 wrote:
> > 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
>
>
> then it is clear that neither oneway nor oneway:foot apply (both are legal 
> prescriptions and not just recommendations).

I agree with you 100% with oneway on ways.

On routes, I'm not so sure.  If a route runs in only one direction,
and you follow its constituent ways in the opposite direction, you're
not following the route. It's an existential, rather than a legal
question, and I'm not enough of a philosopher to solve it.

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

Re: [Tagging] Hotel dataset import? / Re: Baby-sitting

[Martin Koppenhoefer]

sent from a phone

> On 13. Mar 2019, at 16:34, Sergio Manzi  wrote:
> 
> ... an example of massively imported data (which I agree with, btw...): 
> https://blogs.bing.com/maps/2018-06/microsoft-releases-125-million-building-footprints-in-the-us-as-open-data


This data wasn’t generally imported AFAIK (I believe a small part of it was 
imported). Here’s the wiki page: 
https://wiki.openstreetmap.org/wiki/Microsoft_Building_Footprint_Data

here an import:
https://wiki.openstreetmap.org/wiki/Microsoft_Building_Import_-_North_Central_Texas


Cheers, Martin 


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

Re: [Tagging] Hotel dataset import? / Re: Baby-sitting

[Sergio Manzi]

On 2019-03-13 20:22, Martin Koppenhoefer wrote:
>
> On 13. Mar 2019, at 16:34, Sergio Manzi mailto:s...@smz.it>> 
> wrote:
>
>> ... an example of massively imported data (/which I agree with, btw.../): 
>> https://blogs.bing.com/maps/2018-06/microsoft-releases-125-million-building-footprints-in-the-us-as-open-data
>
>
> This data wasn’t generally imported AFAIK (I believe a small part of it was 
> imported). Here’s the wiki page: 
> https://wiki.openstreetmap.org/wiki/Microsoft_Building_Footprint_Data
>
> here an import:
> https://wiki.openstreetmap.org/wiki/Microsoft_Building_Import_-_North_Central_Texas
>
>
> Cheers, Martin


Yes, right: it wasn't "/massively imported data/" but "/a massive amount of 
data which is being imported/".

Thanks for pointing out.

Sergio



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Mapping deforestation wikipage

[Lorenzo Stucchi]

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] Hotel dataset import? / Re: Baby-sitting

[Sergio Manzi]

On 2019-03-13 19:04, Volker Schmidt wrote:
> On Wed, 13 Mar 2019 at 15:45, Sergio Manzi mailto:s...@smz.it>> 
> wrote:
>
> Have mappers walked along the whole world coastlines? Have they descended 
> all world's rivers by canoe?
>
> No, these are examples where imports make sense as these are feature that 
> change slowly (normally) 
>
> Have all Mumbay, New York, Rome, Shanghai, etc., streets and alleys been 
> walked by volunteers mapping their location and names?
>
> No, but many have been photographed and the photographs are available with 
> open license (Mapillary and OpenStreetCam) and many raods have been recorded 
> with GPX tracks. This allows armchair mapping with high quality results, 
> where the mapper does not need to be the photographer.
> New York on OpenStreetCam 
> , 
> Amsterdam on Mapillary 
> 
>
> All the peaks escalated?
>
> Again classical data that change slowly, where imports are justified.
>
> But when you start importing trees or buildings or hotels or petrol stations 
> or shops or crops than you are importing  perishable data which are 
> maintained outside OSM, and hence need frequent updates, with the obvious 
> cost that they need to be updated in the external source database and in the 
> OSM database in synchronism.
>
> Volker


Fair enough, Volker, I agree on all your points. But let's recap, if you don't 
mind.

My objection was to Tom Pfeifer assertion "/I think you misunderstand. OSM is 
*based **on locally sourced, handcrafted data*. That creates the high quality./"

To me "/based on/" means the bulk of data which constitues OSM foundation.

I also have to admit that as far as concern myself, I'm very much more 
interested in what you call "/data that changes slowly/" and I see that as the 
OSM foundation:

  * natural terrain with all its features like hills, mountains, rivers and 
lakes, forests and land cover in general
  * man made features like highways, canals, buildings, bridges, etc.
  * persistent and generally useful information like street numbers

The above, slowly changing information, is what I think represent OSM "base" 
information, and I don't believe the bulk of the above is "locally sourced, 
handcrafted data", but I'm ready to change my mind if proved wrong.

I also think that, as you correctly pointed out, both me and Peter, (/I 
guess.../) forgot about "armchair mapping" which is neither "import" nor 
"locally sourced" and probably represent a huge amount of data in OSM.



As far as regards Giovanni's import, my position is that I'm pretty sure that 
the work he has done is of high quality, probably much better than many 
"locally sourced" information (/you probably have an idea of the quantity of 
"locally sourced" crap I see here in Venice, mainly self-defined hotels and  
B&B which are... nothing... just the address of people renting their 
rooms/apartment/ and stick a name on it).

Personally I would be much happier if OSM would limit itself to its "base 
layer" and let other data aggregators handle different kind of information: if 
I want an Hotel or a room I can go to Tripadvisor or to Airbnb (/not endorsing 
those //_in any way_//, just an example.../), see if it accepts my pet and my 
credit card and then use OSM to navigate to the address.

Unhappily things are not like this and we are mapping hotels. In this regard I 
strongly tend to trust Giovanni import much more than the "locally sourced" 
data.

Cheers,

Sergio






smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Hotel dataset import? / Re: Baby-sitting

[Sergio Manzi]

On 2019-03-13 21:30, Sergio Manzi wrote:
> I also think that, as you correctly pointed out, both me and *Peter*, (/I 
> guess.../) forgot about "armchair mapping" which is neither "import" nor 
> "locally sourced" and probably represent a huge amount of data in OSM.


My bad! Please read:

I also think that, as you correctly pointed out, both me and *Tom*, (/I 
guess.../) forgot about "armchair mapping" which is neither "import" nor 
"locally sourced" and probably represent a huge amount of data in OSM.



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Use of old_name (was Re: Mapping deforestation)

[Graeme Fitzpatrick]

On Wed, 13 Mar 2019 at 19:07, Marc Gemis  wrote:

> totally off-topic:
>

Indeed :-)


>  I know plenty of people that cannot do that without GPS,


When we were talking about GPSs a few years ago, a mate was telling a story
that one of the ladies he works with didn't show up for work one morning,
with no warning or contact. Tried to ring her at home but no answer. They
were getting a bit concerned when she showed up, about 3 hours late & quite
flustered.

When they asked what was wrong, she said that when she went out to her car,
her GPS wouldn't work, so she couldn't figure out how to get to work, so
finished up having to catch a bus.

She'd been working there for 5 years ... :-)

Thanks

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

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

[Graeme Fitzpatrick]

On Wed, 13 Mar 2019 at 17:54, Mateusz Konieczny 
wrote:

> It will rather reduce discussion. People from OSM wiki are more likely to
> stop commenting rather
> than start using mailing list. And why commenting on talk page would be
> worse than commenting on ml?
>

Sorry, I didn't mean to suggest that any one way was worse (or better) than
another,


> People that participate in mailing list (or Wiki or IRC or forum or slack
> or XYZ) discussions
>

rather that there are too many places that people can discuss proposals. If
the OP has put up a proposal, & is on the List & the wiki discussion page
to explain details & counter arguments, so most people "here" are happy (!)
But at the same time, there's other groups talking about the idea on IRC &
XYZ, who aren't getting any feedback from the OP, so they can convince
themselves it's a bad idea so vote against it.

It would just be good if there was only  place that these discussions on
new proposals took place.

Maybe turn what I said before around - all discussion should be the wiki
discussion page, with the only mention on the List being "This new proposal
- all discussion at this page", & similar on all the other forums, IRC etc ?

On Wed, 13 Mar 2019 at 20:42, Jan S  wrote:

> Or promote proposals better, may by consistently (or even automatically)
> linking them on the wiki pages of the affected tags?
>

Yep, like that!

Yeah, I know, so before anyone else says it: https://xkcd.com/927/ :-)

Thanks

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

Re: [Tagging] Hotel dataset import? / Re: Baby-sitting

[Martin Koppenhoefer]

sent from a phone

> On 13. Mar 2019, at 21:30, Sergio Manzi  wrote:
> 
> As far as regards Giovanni's import, my position is that I'm pretty sure that 
> the work he has done is of high quality,
> 

the thing is, Giovanni can do the best work in the world, the resulting data 
will still completely depend on the external dataset.



> probably much better than many "locally sourced" information (you probably 
> have an idea of the quantity of "locally sourced" crap I see here in Venice, 
> mainly self-defined hotels and  B&B which are... nothing
> 

the situation in tourist hotspots is generally different from other areas (much 
more activity in general, and more SEO activity), the Venice map is not 
representative for most of OSM, it is representative for tourist areas.


> if I want an Hotel or a room I can go to Tripadvisor or to Airbnb (not 
> endorsing those in any way, just an example...), see if it accepts my pet and 
> my credit card and then use OSM to navigate to the address.
> 

Remote areas apart, I would not use OSM to search for a place to stay either. 
Usually the main criteria are location, standard, availability and price, of 
which only location can be answered with OSM data.
Still I believe the location of hotels is an interesting geographic 
information. You can do more with the hotel information than searching for a 
hotel to stay.

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

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

[Sergio Manzi]

On 2019-03-13 22:57, Graeme Fitzpatrick wrote:
> It would just be good if there was only  place that these discussions on new 
> proposals took place.

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?

Sergio




smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Graeme Fitzpatrick]

On Thu, 14 Mar 2019 at 00:05, Paul Allen  wrote:

> or should I stick to eating babies as that would be more socially
> acceptable?
>

I guess that sort of depends on whether or not they're Irish babies
https://en.wikipedia.org/wiki/A_Modest_Proposal

& we're having Roast Peasant under Glass for dinner tonight - feel like
joining us? :-)

& as for super-relations - ??? :-)

Thanks

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

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

[Jo]

I think we should move to subrelations for bus routes at some point.
Actually doing it is somewhat tricky. We'd definitely need editor support
to show that a route which consists of subroutes is continuous or not. The
biggest point of contention seems to be whether the stops should go into
the subroute relations as well. I'd say no. Keep the stop sequences for a
particular variation in itinerary together in a route relation per
variation. And only use the subroutes to collect continuous sequences of
ways.

At the same time, some people would think it's more logical to have a
sequence of ways, then a stop, then the next sequence, a stop, and so on.
For that too, it would be nice to have editor support that shows that the
way before and the way after actually connects, or not.

If we go the way of subroutes for PT routes, I/we can probably coerce a
GSoC student to create support for it in PT_Assistant over the summer.

Polyglot

On Wed, Mar 13, 2019 at 11:20 PM Graeme Fitzpatrick 
wrote:

>
>
> On Thu, 14 Mar 2019 at 00:05, Paul Allen  wrote:
>
>> or should I stick to eating babies as that would be more socially
>> acceptable?
>>
>
> I guess that sort of depends on whether or not they're Irish babies
> https://en.wikipedia.org/wiki/A_Modest_Proposal
>
> & we're having Roast Peasant under Glass for dinner tonight - feel like
> joining us? :-)
>
> & as for super-relations - ??? :-)
>
> Thanks
>
> Graeme
> ___
> 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

[Joseph Eisenberg]

> “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. 😂😁

[guilty as charged ☺️]

Seriously though, it’s much more helpful if authors of proposals get as
much advice as possible before going to a vote.

But y’all could try to be nicer and more constructive in comments on new
tags.

Not everyone shares the north-western European value of frank / blunt /
direct criticism.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Warin]

On 14/03/19 00:36, Martin Koppenhoefer wrote:
Am Mi., 13. März 2019 um 14:31 Uhr schrieb Sergio Manzi >:


If a "/superroute/" has an official status (/like this one:
https://www.openstreetmap.org/relation/20773/), I'm all-in for that.

If instead it is something "/invented/" by the mapper, than I'm
all-against it.

Can you please provide more information/examples/context?



there are really long relations (e.g. Via Francigena / St. Francis 
Way, or European E-Routes, which cross half of Europe). Splitting them 
into smaller pieces helps reducing editing conflicts (2 people editing 
the same object at the same time). This is often done along 
administrative boundaries (regional, national).




Supper relation 176684 the Bicentennial National Trail is over 5,000 km 
long, split into 4 sub relations at present.



Many bus routes in cities follow the same route in small sections. It 
would be hand for them to share that part as a sub route - meaning any 
updating of that sub route (people adding turn restrictions, parking, 
curbing etc) only changes that sub route rather than 4 or more 
individual bus routes.



--

The splitting of a relation into sub relations is done for many reasons. 
Making it easier for the mapper is of primary importance. I did see on 
the wiki that relations are better with a maximum of 300 members .. 
weather that is true or not I don't know. But it doe make sense that 
with a lot of members the relation becomes harder to handle for both 
maintenance and rendering.



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

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

[Graeme Fitzpatrick]

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?

Then how do you work together? I don't think we've got any secret pages
that are locked against outsider access?

Also, when do you decide that we're going to need a secret meeting to plot
this out - some things that seem complicated will turn out to be "change
always to usually & it's good to go" & vice versa.

Please don't get me wrong - it's an interesting idea & may well prove to be
a good way to go!

Thanks

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

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

[Paul Allen]

On Wed, 13 Mar 2019 at 22:42, Jo  wrote:

> I think we should move to subrelations for bus routes at some point.
> Actually doing it is somewhat tricky. We'd definitely need editor support
> to show that a route which consists of subroutes is continuous or not.
>

Not a big problem.  Not compared with sorting the route I just had to sort
(again).  Dunno if I messed
up last time I sorted it or what, but it's a major pain.  Maybe I need a
different JOSM plugin, but I
already find JOSM confusing enough.

One problem I found with JOSM was zooming to a way in the relation when
that way appears more
than once.  I did that a lot so I could check the next way in the route was
even in the table or
had to be added.  But if a way appears more than once in a route (as
several do in the one
I was working on) then JOSM moves to the first occurrence of it in the
table of ways, rather than
the one I just selected.

If I could use a superroute then I would choose the subroutes so that no
way appears twice
in a subroute.  That's a problem with circulars that non-circulars don't
have (most of the time
a non-circular has two variants A->B and B->A and although most of the ways
are common to
both they're separate relations).  A truly circular wouldn't have that
problem either, but this one
has loops and repeats and side-branches that aren't loops.


> The biggest point of contention seems to be whether the stops should go
> into the subroute relations as well. I'd say no. Keep the stop sequences
> for a particular variation in itinerary together in a route relation per
> variation. And only use the subroutes to collect continuous sequences of
> ways.
>
> At the same time, some people would think it's more logical to have a
> sequence of ways, then a stop, then the next sequence, a stop, and so on.
> For that too, it would be nice to have editor support that shows that the
> way before and the way after actually connects, or not.
>

That's the other problem I have.  A stop which isn't a stop the first time
the bus passes along
a way but is a stop the second time.  Although the ordering of stops does
mean it's possible to
figure out if you inspect the relation closely, it's not obvious.  Allowing
stops to intersperse the
ways would make it slightly easier to figure out.  But using a superroute
makes it very clear:
it's not a stop on segment 1 but it is a stop on segment 2.  So I'd
definitely want stops on the
subroutes not the superroute.  I think it makes more sense that way
anyway.  It keeps the
stops with the associated ways.

If we go the way of subroutes for PT routes, I/we can probably coerce a
> GSoC student to create support for it in PT_Assistant over the summer.
>

All the tools I need to make life a LOT easier by splitting the route into
subroutes are there.
Breaking the route up manually is relatively simple (takes several steps
and some time, but
very little thought), and after that it just gets far, far easier to deal
with short segments than
one big, looping, wandering route.  If I choose the subroutes wisely I can
even let JOSM sort
them for me (it gets very confused with this route where several ways are
traversed more than
once).

There are only three things stopping me doing that right now:

1) What the response to my post was.  So far nobody has said that it's a
really bad idea since
I posted details of the route.  Unless there are many howls of outrage,
I'll assume it's not
an outrageously bad idea.

2) How to differentiate between the different segments.  I can't use from
and to because those are
supposed to be terminal destinations (preferably as shown on the bus
itself).  So I need a new
tag (or two).  I could get by with something like segment="A to B",
segment="B to C" etc.  But
there's probably a better way of doing it.  And I'd like to do that both
for human readability when
mapping and to allow umap a way of distinguishing between subroutes with an
overpass
query.

3) What else I haven't thought of.  What's show-stopper might turn up after
I've spent time
splitting the route.

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

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

[Joseph Eisenberg]

Normally we should map features that are “real” and “current”, and is
easiest to do for things that can be observed in person.

This suggests mapping each patch of trees as a separate polygon or closed
way, based on having the same leaf_type and leaf_cycle. Usually it’s only
necessary to use a multipolygon when there is a hole in a donut-shaped
woodland. Each area should be tagged natural=forest or natural=wood in
addition to the leaf_type/leaf_cycle tags

So then the problem is, how do you show that all of these patches of trees
are part of one “forest”?

How can another mapper verify where the named “forest” ends? Is it a type
of boundary=protected_area that is designated by the local government or
private landowner? Is there a fence around the whole area? It looks like it
is not a single continuous area, so this makes it even harder to verify
where the named forest ends.

I don’t know much about the original poster’s example, but it looks like
the name is “ Communal Forest”, and the areas included in the
relation are on separate sides of the village and divided by farmland.
Also, there are other areas of woodland right next to the edge of this
forest.

Perhaps this is mapping land ownership parcels rather than a “real”
physical feature?

-Joseph

On Wed, Mar 13, 2019 at 11:14 PM marc marc 
wrote:

> Le 13.03.19 à 14:59, David Marchal a écrit :
> > the JOSM validator claims that contiguous outer members is an error
>
> yes it's- the sum of all outer should not have a "internal" way
> like this one
> https://www.openstreetmap.org/relation/9393253#map=17/48.42219/5.92713
> so draw a new way for the outer of this part
> or split currents ways to include only the outer part in the relation
> and make another relation for the leaf_type
>
>
> > openstreetmap.org renders a misplaced name
>
> It doesn't seem so misplaced
> https://www.openstreetmap.org/#map=15/48.4222/5.9197
> but that's not due to the tag
>
> > no leaf_type
>
> it's hard to render a forêt with several leaf_type
> you may put natural=wood landcover=trees to every part of the forêt
> having a different leaf_type
> but you 'll have a duplicate forest : a foret at the relatin level and
> at every part. currently i'm not aware of a good schema to avoid this
> (you can trick some QA tools by using landuse=forest for the
> relationship and natural=wook for all parts, but see the wiki for
> forest, the meaning of these 2 tags is random/variable depending on the
> mapper, the only meaning you can get is "there are trees", the same
> meaning for the 2 tag)
>
> Regards,
> Marc
>
> ___
> 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

[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. See 
> https://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 07:00 is referring to
> 07:00 on the next day.
>
> Any thought on the proposal?
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
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.




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.



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.


landcover =artificial 



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


landcover =cultivated 
. 

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


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.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Sergio Manzi]

On 2019-03-14 00:03, Joseph Eisenberg wrote:
> > “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. 😂😁
>
> [guilty as charged ☺️]


All the silly funny faces do not makes any less *_vile_* your attempt to put in 
my words meanings that were not expressed nor implied.

I never talked about /illuminati /or a conspiring elite: I was talking about 
people working in team, in a friendly way, to collectively bring out ideas.

IMHO ideas that comes out from a group debate have far more odds to be accepted 
by the community: that's all.


> Seriously though, it’s much more helpful if authors of proposals get as much 
> advice as possible before going to a vote. 
>
> But y’all could try to be nicer and more constructive in comments on new tags.
>
> Not everyone shares the north-western European value of frank / blunt / 
> direct criticism.

I understand that, as I understand how other cultures have different way to 
express their feelings, but I hope people of different cultures, here, have the 
intelligence to understand where I come from and what my real intents are.

Apparently I'm an optimist.




smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Expand the key:opening_hours

[Simon Poole]

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. See 
>> https://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 07:00 is referring to
>> 07:00 on the next day.
>>
>> Any thought on the proposal?
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Sergio Manzi]

On 2019-03-14 00:26, Graeme Fitzpatrick wrote:
>
> On Thu, 14 Mar 2019 at 08:06, Sergio Manzi mailto:s...@smz.it>> 
> 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?

Honestly there is no conspiratory intent in what I'm talking about.

How would I pick them? Say that I want to make a proposal about how to tag 
"cauliflower fields": I'll try to get in touch via email with others that have 
already expressed their interest in something similar (/e.g. artichokes 
fields/) and ask if they are interested in working with me on my new fantastic 
idea of tagging "cauliflower fields" and/or if they know anybody else that they 
think could be interested.


> Then how do you work together? I don't think we've got any secret pages that 
> are locked against outsider access?

No need for that. You can use good-old email, WhatsApp, Telegram, Signal, 
Slack, IRC, ... whatever.

There is no need for that interaction to go through channels directly handled 
by OSM


> Also, when do you decide that we're going to need a secret meeting to plot 
> this out - some things that seem complicated will turn out to be "change 
> always to usually & it's good to go" & vice versa.

Ooops... sorry... I'm afraid I don't understand the meaning of the above. Can 
you please repharase?


> Please don't get me wrong - it's an interesting idea & may well prove to be a 
> good way to go!
>
> Thanks
>
> Graeme

Cheers!

Sergio



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Warin]

On 14/03/19 02:37, 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)

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?


https://wiki.openstreetmap.org/wiki/Tag:route%3Dhiking says

"to indicate that the route is to be walked in only one direction, according to the 
signposts on the ground"

So ONLY in one direction.

https://wiki.openstreetmap.org/wiki/Tag:route%3Dfoot

"to indicate that the route is to be walked in only one direction, according to the 
signposts on the ground"

So ONLY in one direction.

The signposts on the ground should state something about 'one way only".

If the signpost don't say anything about one way only but are aligned it a 
particular direction then oneway=recommended is a better value to use.

TheLarapinta Trail relation 3066363 is such a trial - the signs are 
oriented best for an east to west walk. But you can walk it in any 
direction.



Where the confusion arises is the "recommendation of direction" rather than the 
direction being compulsory.

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

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

[Warin]

+ 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???

Then sub tags for gateway=*.


On 13/03/19 21:32, Joseph Eisenberg wrote:
A Torii is not exactly an arch, but it is a gateway (at least 
symbolically). Perhaps man_made=gateway is a more general term, which 
can incude archways as well as rectangular gateways


If you would like, you can start a proposal page.

On Wed, Mar 13, 2019 at 7:26 PM Tony Shield > wrote:


Been wondering for months how to tag arches in general - not a
mention
in Wiki.

I do like man-made = arch.

I do think that there are several major types of arch which help, so
this discussion started with torii and a possible answer is given as

Perhaps they could be man_made=archway and archway=torii?

The archway tag could have values such as torii, triumphal-arch
(Arc de
Triomphe in Paris, Marble Arch in London), roman-gate. Suitable
values
for others will be needed.

It seems to me that many arches have a deep cultural significance,
often
they were constructed to be significant in that respect, so I would
expect memorial or possibly religious tags to be associated with
an arch.

How to proceed? If there is agreement does it need voting on? Or
can the
wiki be expanded to show this as a tag?

Regards

TonyS

On 13/03/2019 08:35, Martin Koppenhoefer wrote:
>
> sent from a phone
>
>> On 13. Mar 2019, at 01:35, Joseph Eisenberg
mailto:joseph.eisenb...@gmail.com>>
wrote:
>>
>> We considered man_made=gantry (which in general can be used
>> for any sort of structure than goes over a road) or
man_made=archway.
>
> +1, there is also man_made=arch (32 uses vs 7 for archway)
>
>
>> There was also a suggestion to tag some of these structures as
a type
>> of artwork, although this is only sometimes relevant.
>
> +1, add additionally artwork if you consider the thing a work of
art.
>
>
> The section of road itself passing under the arch could be
tagged with covered=yes, this is a hint for the renderer
>
>
> 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



___
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?

[Warin]

On 14/03/19 10:36, Joseph Eisenberg wrote:
Normally we should map features that are “real” and “current”, and is 
easiest to do for things that can be observed in person.


This suggests mapping each patch of trees as a separate polygon or 
closed way, based on having the same leaf_type and leaf_cycle. Usually 
it’s only necessary to use a multipolygon when there is a hole in a 
donut-shaped woodland. Each area should be tagged natural=forest or 
natural=wood in addition to the leaf_type/leaf_cycle tags


+1


So then the problem is, how do you show that all of these patches of 
trees are part of one “forest”?


How can another mapper verify where the named “forest” ends? Is it a 
type of boundary=protected_area that is designated by the local 
government or private landowner? Is there a fence around the whole 
area? It looks like it is not a single continuous area, so this makes 
it even harder to verify where the named forest ends.


A site relation could be the best solution?


I don’t know much about the original poster’s example, but it looks 
like the name is “ Communal Forest”, and the areas 
included in the relation are on separate sides of the village and 
divided by farmland. Also, there are other areas of woodland right 
next to the edge of this forest.


Perhaps this is mapping land ownership parcels rather than a “real” 
physical feature?


-Joseph

On Wed, Mar 13, 2019 at 11:14 PM marc marc > wrote:


Le 13.03.19 à 14:59, David Marchal a écrit :
> the JOSM validator claims that contiguous outer members is an error

yes it's- the sum of all outer should not have a "internal" way
like this one
https://www.openstreetmap.org/relation/9393253#map=17/48.42219/5.92713
so draw a new way for the outer of this part
or split currents ways to include only the outer part in the relation
and make another relation for the leaf_type


> openstreetmap.org  renders a misplaced
name

It doesn't seem so misplaced
https://www.openstreetmap.org/#map=15/48.4222/5.9197
but that's not due to the tag

> no leaf_type

it's hard to render a forêt with several leaf_type
you may put natural=wood landcover=trees to every part of the forêt
having a different leaf_type
but you 'll have a duplicate forest : a foret at the relatin level
and
at every part. currently i'm not aware of a good schema to avoid this
(you can trick some QA tools by using landuse=forest for the
relationship and natural=wook for all parts, but see the wiki for
forest, the meaning of these 2 tags is random/variable depending
on the
mapper, the only meaning you can get is "there are trees", the same
meaning for the 2 tag)


-1. Best not to try and 'trick' things, gets confusing too quickly.

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

Re: [Tagging] Expand the key:opening_hours

[Warin]

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 07:00 is referring to
07:00 on the next day.

Any thought on the proposal?



Think best to separate it from the present opening hours.

Perhaps   opening_hours:persian=* (example - where the Persian calendar 
is in use).???




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

Re: [Tagging] Expand the key:opening_hours

[Sergio Manzi]

On 2019-03-14 01:28, Warin wrote:
> Think best to separate it from the present opening hours.
>
> Perhaps   opening_hours:persian=* (example - where the Persian calendar is in 
> use).???

Good idea!

Sergio




smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Paul Johnson]

On Wed, Mar 13, 2019 at 8:19 AM Paul Allen  wrote:

> I've hesitated to ask this question for months now: what's the
> consensus on superroutes?
>

Coherently and cogently mapping large countries with long routes (such as
the United States) would be essentially impossible without them.  I think
the current relation member limit is arbitrarily set to what fits in an 8
bit value IIRC; throw in everything that can cause a break (bridges,
changes in weight, speed and length maximums and minimums, whether or not
something is toll, lane counts and placement, turn lane status, etc) and it
wouldn't surprise me if states like Texas or California might have to start
using county-by-county child relations within a superrelation in order to
keep it all under the member limit in the foreseeable future.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Expand the key:opening_hours

[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 07:00 is referring to
> >>> 07:00 on the next day.
> >>>
> >>> Any thought on the proposal?
> >>>
>
> Think best to separate it from the present opening hours.
>
> Perhaps   opening_hours:persian=* (example - where the Persian calendar
> is in use).???
>
>
>
> ___
> 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.

[Martin Koppenhoefer]

sent from a phone

> On 13. Mar 2019, at 10:54, Tony Shield  wrote:
> 
> How to proceed? If there is agreement does it need voting on? Or can the wiki 
> be expanded to show this as a tag?


if you want to vote, you should create a proposal for it. Otherwise you can put 
a proposal as well :)

Most importantly, use the tags. 


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

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

[Warin]

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

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