Re: [Tagging] Tagging of State Parks in the US

[Graeme Fitzpatrick]

All looks OK at first glance, Kev, except for one minor typo - you've got
two Class 25's - I assume Historic should actually be 26?

Will have a fuller read later :-)

Thanks

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

Re: [Tagging] Road hierarchy

[Florian Lohoff]

On Mon, Aug 05, 2019 at 12:30:48AM +0100, Paul Allen wrote:
> On Mon, 5 Aug 2019 at 00:12, Martin Koppenhoefer 
> wrote:

> I just reverted it.  And added some clarification (some may disagree and
> think I've murkified it)
> based on why I think those words were removed back in February.  Feel free
> to fix my fixes.

Your statement added:

"but which are not normally used as through routes (which would usually 
be
classified highways or unclassified highways)."

I disagree on this. I dont think we have consensus that residential
are not for through traffic. Our routers/navigators dont treat it like
that. And if we assume so there is a HUGE difference in unclassified and
residential we dont actually yet have.

And its not the claim which has been removed in February.

"but which are not a classified or unclassified highways."

This is a statement which unclassified carries aswell:

In short, when other highway=* tags are more applicable, use those
instead. If a public road is of lesser importance than what's called a
highway=tertiary in your region, and is also not a highway=residential, 
a
highway=service, or a highway=track, then it's probably an unclassified 
road."  

So the statement removed in February  is a "NOOP" statement. Saying

"you cant be A if you are B"

Now you changed it to something completely different with additional claims.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Tagging] Road hierarchy

[Florian Lohoff]

On Sun, Aug 04, 2019 at 07:55:16PM +0100, ael wrote:
> On Sun, Aug 04, 2019 at 04:23:03PM +0200, Martin Koppenhoefer wrote:
> > sent from a phone
> > > On 4. Aug 2019, at 15:37, Florian Lohoff  wrote:
> > > A residential is also an unclassified road.
> > 
> > IMHO it is not, as an unclassified road is part of the interconnection 
> > grid, while a residential road is not 
> 
> My reply was going to be much the same. Unclassified roads are generally
> for "through traffic". Residential raods are primarily for access to
> those buildings, and would not (normally) be used for travel to other
> destinations.

No statement in the Wiki backs up this claim. This is what i say.

No statement about through traffic. Residentials are for through
traffic aswell although their primary purpose may be access to the
residential area.

This is what our algorithmic brothers in routing/navigation do. Treating
unclassified and residential the same.

And we cant distinguish these 2 by hard facts. Its more or less "felt
traffic pattern" or "believe" or "experience" how you tag.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Tagging] Road hierarchy

[Florian Lohoff]

On Sun, Aug 04, 2019 at 04:21:14PM +0200, Martin Koppenhoefer wrote:
> I don’t think this is a valid conclusion:
> 
> - we are not restricting our tagging to official denominations but
> give precedence to on the ground usage

Correct - But from my experience its either a service or it has
a name. At least in the part of Germany where i map.

There are of course the 1% of exceptions where Bayer or BASF names roads
on their facility property. But the typical parking aisle or
access to a fuel station should not carry a name.

And naming driveways as the roads they originate from is broken. The
driveway itself does not have a name.

For me this is also a matter of housekeeping the search index in
nominatim. If i search for Bahnhofstraße is typically dont want
to find 100's of Driveways named Bahnhofstraße.
 
> - the service class is further divided into many different classes
> like driveways, alleys, parking aisles, drive through ways, minor
> generic access roads, etc., some may have names, many will usually not
> carry a name.

Which of those do carry names typically? I cant see any? And its just
my mapper experience in the wider area i map that we typically dont have
names. And if they are named its a bug in 97% of the cases.

And in the QA i do i do not flag 100% issues - but objects you might
want to take a look at because they are fishy. And typically its not
just that one object but some blocks which have been mapped with strange
assumptions.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Tagging] Tagging of State Parks in the US

[Kevin Kenny]

On Sat, Jul 27, 2019 at 8:24 PM Joseph Eisenberg
 wrote:
> I think it may be difficult to get protect_class=21 rendered, unless the tag 
> is more precisely defined. While you are using this tag specifically for 
> recreation related protected areas, the current wiki page says that it can be 
> used for
> 3 options:
>
> 1) make a proposal to redefine the meaning of [...]
> 2) make a proposal for a new protect_class [...]
> 3) create a new tag, [...]


OK, so here we appear to stand.

Nobody appears to have a substantive objection to considering state
parks as protected areas. The chief objection appears to be that the
existing numeric scheme for protection categories is non-mnemonic and
awkward (to which I agree wholeheartedly!)

I had earnestly hoped to avoid the pain of coming up with a tagging
proposal, in favor of codifying 'best current practice' for tagging
state parks (and, it is hoped, quieting some of the arguments about
it, which had grown quite heated). In fact, before posting here, I'd
ran the proposal by a handful of the most strident users in the
arguments, and actually managed to elicit agreement in principle. My
hope was that a new tagging scheme would be Out Of Scope for the
current discussion.

Nevertheless, the dissatisfaction with the numeric labels will, as far
as I can tell, sink any hope of getting these objects rendered, and
will likely lead to further unproductive arguments on the Wiki.
Accordingly, it appears necessary, however distasteful I find it, to
propose a relabeling of protection classes before considering any
proposal to tag state parks and similar features to be in its final
form.  Accordingly, I'm starting to draft such a proposal at
https://wiki.openstreetmap.org/wiki/Proposal:_Named_protection_class_for_protected_areas.

So far, I've just sketched a set of values that correspond to the
common (95% or so) cases that 'taginfo' turns up. As with any key
we've ever identified, there are outlier values that cannot really be
addressed (typos, invented values, multiple values, and a variety of
nearly inexplicable things).

Most of the sections are still stubbed; of course, I can grind out
text for them, I just haven't done it yet. I've most likely got some
of the details wrong in what I have written. That's why it's called a
'draft' - please assume that I'm approaching this with good will.

I'm also rather poor at the Naming of Names. I'm hoping against hope
that this idea will not founder on fine details of word choice.
Clearly, not every value will please everyone.

Suggestions are, of course, welcome, bearing in mind the above caveats.

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

Re: [Tagging] Tagging of bullrings

[Jmapb]

On 8/4/2019 7:09 PM, dcapillae wrote

I have asked the OSM community in Spain and it seems that some mapper prefer
"building=bullring" instead of "building=stadium". I think the right tag is
"building=stadium" because we use this tag for stadiums, no matter what type
of stadium they are, and a bullring is a stadium. However, I guess there's
not much difference.


The question as I see it is: When you look at the building in question,
do you think "this building looks like a bullring" or do you think "this
building looks like a stadium, and bullfighting is the primary sport here"?

I don't know if there's a distinct style of traditional bullring
architecture, but if there is, then building=bullring makes sense for
those. (And in fact such buildings might still be tagged
building=bullring even if bullfighting no longer happens there.)

Furthermore, if a more generic-looking stadium were built that was not
in the distinctive bullring style, but was still primary used for
bullfights, then building=stadium might be a better choice for that one.

J


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

Re: [Tagging] Multiple values in isced:level

[Warin]

On 05/08/19 11:46, ET Commands wrote:



Ask any two people on this list their opinion on any matter and you will
get THREE opinions.
At least.

--
Paul



+1000


And if you read the wiki you can add another 3 opinions to that.

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

Re: [Tagging] Multiple values in isced:level

[Andrew Harvey]

On Mon, 5 Aug 2019 at 08:36, Graeme Fitzpatrick 
wrote:

> In Australia, at least, that would mean Unit (Room / Suite / Office etc) 1
> (House / Street) Number 3; 3/4 would be Unit 3 Number 4 etc
>

Which would be more explicit if mapped as addr:unit=3 + addr:housenumber=4.
Then downsteam consumers can decide to render as either 3/4 or Unit 3, 4...
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Multiple values in isced:level

[ET Commands]

Ask any two people on this list their opinion on any matter and you will
get THREE opinions.
At least.

--
Paul



+1000


Mark



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

Re: [Tagging] Tagging of bullrings

[dcapillae]

dieterdreist wrote
> I would also prefer either building=bullring or maybe we need a stadium=*
> tag.

Yes, my first idea was to use a "stadium" subtag. This solution is barely
used, so I dismissed the idea.

I preferred "building=stadium" + "stadium=bullring" to "building=bullring"
if some of these solutions were used. However, the problem with bullrings in
Spain is that each mapper was mapping them differently. The proposed
solution, in line with the established system, would probably solve the
problem. 

Greetings for Spain, and thank you for commenting.

Regards,
Daniel



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

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

Re: [Tagging] Road hierarchy

[Paul Allen]

On Mon, 5 Aug 2019 at 00:12, Martin Koppenhoefer 
wrote:

this should be reverted, and I would be glad if someone did it now, because
> I cannot do it myself at the moment. Thank you.
>

I just reverted it.  And added some clarification (some may disagree and
think I've murkified it)
based on why I think those words were removed back in February.  Feel free
to fix my fixes.

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

Re: [Tagging] Tagging of bullrings

[Martin Koppenhoefer]

sent from a phone

> On 5. Aug 2019, at 01:09, dcapillae  wrote:
> 
> I have asked the OSM community in Spain and it seems that some mapper prefer
> "building=bullring" instead of "building=stadium". I think the right tag is
> "building=stadium" because we use this tag for stadiums, no matter what type
> of stadium they are, and a bullring is a stadium. However, I guess there's
> not much difference.


I would also prefer either building=bullring or maybe we need a stadium=* tag.

Cheers Martin 


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

Re: [Tagging] Road hierarchy

[Martin Koppenhoefer]

sent from a phone

On 4. Aug 2019, at 16:50, Florian Lohoff  wrote:

>> Residential roads are the roads inside the residential area, which are
>> not used by through traffic
> 
> Where do you take this assumption from? I have never heard before that
> residential may not be used for through traffic?



sorry, I was not precise, what I meant to say was that residential roads are 
not intended for through traffic. According to the context (e.g. oneway and 
dead end, or a grid) you may be able to “bypass the main traffic” and be faster 
(when the principal road is congested), but you are not supposed to do it, and 
it will usually be slower (slower speeds, pedestrians, no right of way at 
crossings, penalized at traffic lights etc.). Or in another context it will not 
be possible to go “through” a residential area, you can only enter and leave 
“at the same side”.

You may sometimes/often be able to go through the residential area on 
residential streets, but it doesn’t make them roads for through traffic. The 
roads for through traffic are usually tagged with tertiary+, minor ones with 
unclassified, so they can’t be residential ;-)




> The opposite is described in highway=residential:
> 
> https://wiki.openstreetmap.org/wiki/Tag:highway%3Dresidential
> 
>This tag is used for roads accessing or around residential areas.


Maybe I don’t understand the word “access” correctly here, but if I think about 
an access road to a residential area, it would be different from the 
residential roads in the area. I would suggest to clarify this in the wiki 
(remove access or illustrate what it means).

Anyway, this is the result of an edit from February this year, where the 
long-standing definition was changed by removing this:
but which are not a classified or unclassified highways.


https://wiki.openstreetmap.org/w/index.php?title=Tag:highway%3Dresidential=revision=1789326=1526745


this should be reverted, and I would be glad if someone did it now, because I 
cannot do it myself at the moment. Thank you.


Cheers Martin 


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

Re: [Tagging] Tagging of bullrings

[dcapillae]

Thank you, Martin.

I think it's the right thing to do, too.

I have asked the OSM community in Spain and it seems that some mapper prefer
"building=bullring" instead of "building=stadium". I think the right tag is
"building=stadium" because we use this tag for stadiums, no matter what type
of stadium they are, and a bullring is a stadium. However, I guess there's
not much difference.

Thank for commenting.

Regards,
Daniel 



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

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

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

[Janko Mihelić]

Isn't the only thing that matters, for routing at least, the name of the
role that the platform has? I mean, anything can have the role "platform".
Highway=bus_stop can have the role platform.

And nothing renders anyway. So why don't we just start using other
public_transport values, like pole, waiting_area, and whatever we want. We
just start using them, and give them the "platform" role in the relations.
Rendering will come.

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

Re: [Tagging] Multiple values in isced:level

[Graeme Fitzpatrick]

On Mon, 5 Aug 2019 at 07:14, Martin Koppenhoefer 
wrote:

>
> if these were housenumbers, what about 1/3 ?
>

In Australia, at least, that would mean Unit (Room / Suite / Office etc) 1
(House / Street) Number 3; 3/4 would be Unit 3 Number 4 etc

Thanks

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

Re: [Tagging] Multiple values in isced:level

[Martin Koppenhoefer]

yes, I guess the usual case of splits in systems with consecutive numbers 
running down the road is made with letters, because 1B is clearer than 1/2, but 
in reality you can find both.

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

Re: [Tagging] Multiple values in isced:level

[Martin Koppenhoefer]

sent from a phone

> On 4. Aug 2019, at 16:58, Paul Allen  wrote:
> 
> There are several different views on this.  Mine would be 1-3 means 1;2;3 and 
> 1,3 means 1;3.  Oh,
> and 1,2,3 is an alternative to 1-3 but more cumbersome.  However, this is OSM 
> where a foolish
> consistency is never the hobgoblin of our little minds.


if these were housenumbers, what about 1/3 ? 

There might also be 1/1, 1/2 and 1/4, etc., or it could mean 1;3 (1 and 3). The 
latter is quite common in Italy, where every door or gate gets its number, but 
I have also seen the former, where a housenumber has been split into several 
housenumbers.

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

Re: [Tagging] Road hierarchy

[Peter Elderson]

It's supposed to be modeled after the british road system. If the class
exists only in the UK and you're a strictie, then you should not use it
outside the UK.

If you are a non-strictie then you can use the classification únclassified'
for comparable roads, i.e. a class of connecting road in the public grid,
above residential and below tertiary.

Residential is meant to give access to neighbourhoods and houses within a
residential area, as its primary function.

A road outside a residential area can have lots of houses along it's
length, but the primary function is connecting roads to roads, roads to
residential areas, or interconnecting residential areas. I think that is
"unclassified", even where there is no official classification.

So my hierarchy is: ...>tertiary>unclassified>residential>living_street

Woudn't mind calling it quaternary though. Would probably solve the issue.
Of course this will never happen. No consensus, too much work.

Vr gr Peter Elderson


Op zo 4 aug. 2019 om 20:58 schreef Dave Swarthout :

> Peter wrote:
> My research tells me ‘unclassified’ means classified as ‘unclassified‘,
> which is a class of road in the public road system.
>
> I respectfully disagree.
> That is only the case where a country has a class of roads they label or
> call "Unclassified". In Alaska and Thailand, where I do the bulk of my
> mapping, an unclassified highway is just that, it is a highway having no
> classification. I consider it higher in the hierarchy than a residential
> and lower than a tertiary, although some opinions may differ. Whether paved
> or unpaved makes no difference. As long as it connects towns or hamlets in
> a reasonable manner, then it is an unclassified highway.
>
> On Sun, Aug 4, 2019 at 10:49 AM Peter Elderson 
> wrote:
>
>> My research tells me ‘unclassified’ means classified as ‘unclassified‘,
>> which is a class of road in the public road system. Other roads cannot be
>> classified as ‘unclassified’, but should get another classification. Roads
>> without classification need a fixme, not a classification as ‘unclassified’.
>>
>> Mvg Peter Elderson
>>
>> > Op 4 aug. 2019 om 16:23 heeft Martin Koppenhoefer <
>> dieterdre...@gmail.com> het volgende geschreven:
>> >
>> >
>> >
>> > sent from a phone
>> >
>> >> On 4. Aug 2019, at 15:37, Florian Lohoff  wrote:
>> >>
>> >> A residential is also an unclassified road.
>> >
>> >
>> > IMHO it is not, as an unclassified road is part of the interconnection
>> grid, while a residential road is not
>> >
>> > 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
>>
>
>
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at http://dswarthout.blogspot.com
> ___
> 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] Was public_transport=platform intended to always be combined with highway=bus_stop?

[Tim Magee]

On Sunday, August 4, 2019 2:21:11 PM EDT Jo wrote:
> On Sun, Aug 4, 2019, 16:40 Martin Koppenhoefer 
> 
> wrote:
> > it is just an excuse to insist on using pt=platform for things that aren’t
> > platforms and justify it with saying it means waiting area.
> > I don’t think we should define pt=platform for something different than a
> > public transport platform, it would be asking for trouble.
> > If you want a waiting area tag, name it like this.
> 
> That ship has sailed
> 
> Polyglot

I believe this is the number one reason to move beyond PTv2. There is no way 
to meaningfully fix it because public_transit=platform already means something 
that isn't a public transit platform. 

signature.asc
Description: This is a digitally signed message part.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Road hierarchy

[Mark Wagner]

On Sun, 4 Aug 2019 09:35:41 +0300
Tomas Straupis  wrote:

> Hello
> 
>   Road hierarchy is needed for a number of things:
>   * deciding which classes of roads to display on different scales in
> a map
>   * performing road network validation
>   * other tasks (f.e. typification of buildings - orientation)
> 
>   Hierarchy would be different in different context: motorcar,
> bicycle, pedestrian etc. For the time being I'm only asking about
> motorcars.
> 
>   There is non written (or I could not find in wiki) or "de facto"
> hierarchy:
>   * motorway
>   * trunk
>   * primary
>   * secondary
>   * tertiary
>   * unclassified
>   * residential
>   * living_street
>   In some regions unclassified has a higher position in hierarchy, in
> other regions unclassified, residential and living_street have the
> same position. This is fine for the time being.
>   I'm also intentionally skipping _link classes.

The hierarchy is 

* Trunk
* Primary
* Secondary
* Tertiary
* Unclassified/Residential are more or less at the same level.  They're
  minor enough that any difference between them is a matter of local
  opinion.  In general, if you want a complete-looking map, you should
  draw both or neither.

Motorways are defined by their construction standards or legal
classification: think the Autobahn in Germany or Interstates in the US.
They're effectively at the top of the hierarchy, but this is an effect
of the things that make them motorways, not the cause.

Tracks, service roads, and living streets are outside the hierarchy.
Like motorways, they're defined by their attributes, not their
importance, though in this case, the effect of those attributes is to
tend to put them at the bottom of the hierarchy.

Deciding when and how to draw them is a matter of the needs of a map:
for example, a mountain-bike map for US National Forests might
emphasize tracks over hierarchy roads, while a driving map for farm
country might omit them entirely.

-- 
Mark

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

Re: [Tagging] Road hierarchy

[Dave Swarthout]

Peter wrote:
My research tells me ‘unclassified’ means classified as ‘unclassified‘,
which is a class of road in the public road system.

I respectfully disagree.
That is only the case where a country has a class of roads they label or
call "Unclassified". In Alaska and Thailand, where I do the bulk of my
mapping, an unclassified highway is just that, it is a highway having no
classification. I consider it higher in the hierarchy than a residential
and lower than a tertiary, although some opinions may differ. Whether paved
or unpaved makes no difference. As long as it connects towns or hamlets in
a reasonable manner, then it is an unclassified highway.

On Sun, Aug 4, 2019 at 10:49 AM Peter Elderson  wrote:

> My research tells me ‘unclassified’ means classified as ‘unclassified‘,
> which is a class of road in the public road system. Other roads cannot be
> classified as ‘unclassified’, but should get another classification. Roads
> without classification need a fixme, not a classification as ‘unclassified’.
>
> Mvg Peter Elderson
>
> > Op 4 aug. 2019 om 16:23 heeft Martin Koppenhoefer <
> dieterdre...@gmail.com> het volgende geschreven:
> >
> >
> >
> > sent from a phone
> >
> >> On 4. Aug 2019, at 15:37, Florian Lohoff  wrote:
> >>
> >> A residential is also an unclassified road.
> >
> >
> > IMHO it is not, as an unclassified road is part of the interconnection
> grid, while a residential road is not
> >
> > 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
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Road hierarchy

[ael]

On Sun, Aug 04, 2019 at 04:23:03PM +0200, Martin Koppenhoefer wrote:
> 
> 
> sent from a phone
> 
> > On 4. Aug 2019, at 15:37, Florian Lohoff  wrote:
> > 
> > A residential is also an unclassified road.
> 
> 
> IMHO it is not, as an unclassified road is part of the interconnection grid, 
> while a residential road is not 

My reply was going to be much the same. Unclassified roads are generally
for "through traffic". Residential raods are primarily for access to
those buildings, and would not (normally) be used for travel to other
destinations.

ael


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

Re: [Tagging] Road hierarchy

[Peter Elderson]

My research tells me ‘unclassified’ means classified as ‘unclassified‘, which 
is a class of road in the public road system. Other roads cannot be classified 
as ‘unclassified’, but should get another classification. Roads without 
classification need a fixme, not a classification as ‘unclassified’.

Mvg Peter Elderson

> Op 4 aug. 2019 om 16:23 heeft Martin Koppenhoefer  
> het volgende geschreven:
> 
> 
> 
> sent from a phone
> 
>> On 4. Aug 2019, at 15:37, Florian Lohoff  wrote:
>> 
>> A residential is also an unclassified road.
> 
> 
> IMHO it is not, as an unclassified road is part of the interconnection grid, 
> while a residential road is not 
> 
> 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] Was public_transport=platform intended to always be combined with highway=bus_stop?

[Jo]

On Sun, Aug 4, 2019, 16:40 Martin Koppenhoefer 
wrote:

>
> it is just an excuse to insist on using pt=platform for things that aren’t
> platforms and justify it with saying it means waiting area.
> I don’t think we should define pt=platform for something different than a
> public transport platform, it would be asking for trouble.
> If you want a waiting area tag, name it like this.
>
That ship has sailed

Polyglot

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

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

[Markus]

On Sun, 4 Aug 2019 at 16:40, Martin Koppenhoefer  wrote:
>
> it is just an excuse to insist on using pt=platform for things that aren’t 
> platforms and justify it with saying it means waiting area.

To quote the PTv2 proposal page: "The platform is the place where
passengers are waiting for the vehicles. ... If there is no platform
in the real world, one can place a [node] at the pole [...]." [1]

[1]: 
https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Public_Transport=625726

Thus the tag says nothing about the existence of a raised structure.

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

Re: [Tagging] Rethinking Map Features

[Yuri Astrakhan]

Joseph, you don't need to use preferences - just click the language
switcher at the very top of the page, and you only need to switch to
Indonesian and back once -- the interface will always offer both choices to
fill out.  Please see the video, and let me know if what you see is
different. You might be using mobile version of the site?

Filling it out labels in every language is a bit silly - there are
thousands of languages, why would we want to store identical information in
every one of them, when the system automatically does fallback to English?
I could create some sort of a javascript gadget that hides the label column
when the item type is a key/value/relation/relation role (multilingual
labels are still useful for other item types), but some people have already
added some alternative language-specific labels, essentially localizing
keys - not sure if we should just hide those.  BTW, if anyone wants to hack
on it (I'm looking at you Minh :)), it would be awesome!  Or at least we
should maybe give a warning when user tries to add a label identical to
English?

Every wiki page, including the data items have a "history" tab at the top
that will show every edit done to that page.

On Sun, Aug 4, 2019 at 12:17 PM Joseph Eisenberg 
wrote:

> Thanks, yes, changing the language under “preferences” for the wiki works,
> though it’s a little annoying.
>
> You should set the label field for all languages to the key=value or
> remove this field and display the key=value at the top of the page anyway.
> It’s quite distracting Now.
>
> Is there a way to see the wikibase data item history? One big concern I
> have is that it won’t be easy to see when something is changed. Can you get
> notified if someone changes a description?
>
> Joseph
>
> On Mon, Aug 5, 2019 at 1:05 AM Yuri Astrakhan 
> wrote:
>
>> P.S. I made a short video on how to add descriptions and translations
>>
>> https://www.youtube.com/watch?v=rI1NDD4MtC4
>>
>> On Sun, Aug 4, 2019 at 11:56 AM Yuri Astrakhan 
>> wrote:
>>
>>> Joseph, before you click "edit description", change your language at the
>>> top of the wiki page (make sure you are logged in.  Also, if you change the
>>> language a few times to the ones you know, e.g. to Indonesian, to Spanish,
>>> and then to English, I think interface will always offer you to enter
>>> description in the last few you had picked.
>>>
>>> Thanks for adding translations!
>>>
>>> On Sun, Aug 4, 2019 at 11:40 AM Joseph Eisenberg <
>>> joseph.eisenb...@gmail.com> wrote:
>>>
 You're right, I was a little confused. Almost all the features on Map
 Features have a wiki page (and those that don't should get a page or
 more likely be removed), so I understand that they have an OSM
 wikibase entry, now, and creating the data item isn't an issue.

 But I still can't figure out how to add description in another language?

 I tried to get the Indonesian translation by:
 1) Open the English wiki page (eg from the link on Map Features in this
 case)
 2) Click on the little pencil to edit the OSM wikibase data item
 (which I can't see, because I have images disabled, but I just hunt
 around...)
 3) Click on "edit" next to description
 4) Click "all entered languages" - wait, how do I add Indonesian?
 ?

 Maybe I don't see Indonesian because I'm using a satellite internet
 connection from Australia and I haven't edited Indonesian before. I
 try clicking on "Configure" next to "In more languages"

 I don't see Indonesian there either. So perhaps I have to make a new
 wikibase entry for my language? Unfortunately I don't see a link to
 make a new wikibase item.

 Ok, let's try again with Spanish (Español), that's on the list...

 I still can't figure it out. How do I add a description in another
 language?

 Fortunately I can just make a stub wiki page by:

 1) Open the English language page
 2) Click on edit
 3) Copy the url, add "id:" in front of the page name
 4) Copy and paste the ValueDescription / KeyDescription box content
 5) Edit the description to Indonesian

 It looks like that will still be fewer clicks and fewer mouse strokes
 than editing the OSM wikibase data items, and has the benefit of
 creating a visible wiki page rather than just editing an obscure data
 item.

 Joseph

 On 8/4/19, Yuri Astrakhan  wrote:
 > Joseph, could you clarify what you mean by "Map Features entry" ?  If
 you
 > only refer to keys/tags/relations/relation roles, than those things
 are
 > automatically created -- an editor only needs to translate them.
 >
 > I do agree that if we want to store more diverse data items, we need
 > specialized UI, at least for the initial item creation. Luckily,
 there is a
 > large Wikidata community that has already done many such custom UIs.
 For
 > example, Wikidata now 

Re: [Tagging] Rethinking Map Features

[Joseph Eisenberg]

Thanks, yes, changing the language under “preferences” for the wiki works,
though it’s a little annoying.

You should set the label field for all languages to the key=value or remove
this field and display the key=value at the top of the page anyway. It’s
quite distracting Now.

Is there a way to see the wikibase data item history? One big concern I
have is that it won’t be easy to see when something is changed. Can you get
notified if someone changes a description?

Joseph

On Mon, Aug 5, 2019 at 1:05 AM Yuri Astrakhan 
wrote:

> P.S. I made a short video on how to add descriptions and translations
>
> https://www.youtube.com/watch?v=rI1NDD4MtC4
>
> On Sun, Aug 4, 2019 at 11:56 AM Yuri Astrakhan 
> wrote:
>
>> Joseph, before you click "edit description", change your language at the
>> top of the wiki page (make sure you are logged in.  Also, if you change the
>> language a few times to the ones you know, e.g. to Indonesian, to Spanish,
>> and then to English, I think interface will always offer you to enter
>> description in the last few you had picked.
>>
>> Thanks for adding translations!
>>
>> On Sun, Aug 4, 2019 at 11:40 AM Joseph Eisenberg <
>> joseph.eisenb...@gmail.com> wrote:
>>
>>> You're right, I was a little confused. Almost all the features on Map
>>> Features have a wiki page (and those that don't should get a page or
>>> more likely be removed), so I understand that they have an OSM
>>> wikibase entry, now, and creating the data item isn't an issue.
>>>
>>> But I still can't figure out how to add description in another language?
>>>
>>> I tried to get the Indonesian translation by:
>>> 1) Open the English wiki page (eg from the link on Map Features in this
>>> case)
>>> 2) Click on the little pencil to edit the OSM wikibase data item
>>> (which I can't see, because I have images disabled, but I just hunt
>>> around...)
>>> 3) Click on "edit" next to description
>>> 4) Click "all entered languages" - wait, how do I add Indonesian?
>>> ?
>>>
>>> Maybe I don't see Indonesian because I'm using a satellite internet
>>> connection from Australia and I haven't edited Indonesian before. I
>>> try clicking on "Configure" next to "In more languages"
>>>
>>> I don't see Indonesian there either. So perhaps I have to make a new
>>> wikibase entry for my language? Unfortunately I don't see a link to
>>> make a new wikibase item.
>>>
>>> Ok, let's try again with Spanish (Español), that's on the list...
>>>
>>> I still can't figure it out. How do I add a description in another
>>> language?
>>>
>>> Fortunately I can just make a stub wiki page by:
>>>
>>> 1) Open the English language page
>>> 2) Click on edit
>>> 3) Copy the url, add "id:" in front of the page name
>>> 4) Copy and paste the ValueDescription / KeyDescription box content
>>> 5) Edit the description to Indonesian
>>>
>>> It looks like that will still be fewer clicks and fewer mouse strokes
>>> than editing the OSM wikibase data items, and has the benefit of
>>> creating a visible wiki page rather than just editing an obscure data
>>> item.
>>>
>>> Joseph
>>>
>>> On 8/4/19, Yuri Astrakhan  wrote:
>>> > Joseph, could you clarify what you mean by "Map Features entry" ?  If
>>> you
>>> > only refer to keys/tags/relations/relation roles, than those things are
>>> > automatically created -- an editor only needs to translate them.
>>> >
>>> > I do agree that if we want to store more diverse data items, we need
>>> > specialized UI, at least for the initial item creation. Luckily, there
>>> is a
>>> > large Wikidata community that has already done many such custom UIs.
>>> For
>>> > example, Wikidata now stores language data (all lexems), and there is a
>>> > community-created tool to add such words --
>>> > https://tools.wmflabs.org/lexeme-forms/  (I'm not sure if this tool
>>> checks
>>> > for duplicates, please check first if you want to add new data). There
>>> are
>>> > many other tools we can model after.  Best thing -- those tools don't
>>> have
>>> > to be part of the wiki, but can reside anywhere else, and could be in
>>> pure
>>> > client-side JavaScript.
>>> >
>>> > On Sun, Aug 4, 2019 at 2:05 AM Joseph Eisenberg
>>> > 
>>> > wrote:
>>> >
>>> >> So far, I've found it very difficult to create and edit new wikibase
>>> >> entries. I don't think it will be easier for Indonesian mappers to
>>> >> create a wikibase entry for every Map Features entry, rather than
>>> >> creating a stub page with a description.
>>> >>
>>> >> The advantage of translating wiki pages for each features is that then
>>> >> there is a human-readable page which can be updated and expanded over
>>> >> time, and also it's clear where the list of feature descriptions are
>>> >> coming from.
>>> >>
>>> >> If you want everyone to create wikibase entries instead, there needs
>>> >> to be a much easier, friendlier interface, available in all languages,
>>> >> and I think such a major change should be discussed and be implemented
>>> >> only if there is consensus that this would 

Re: [Tagging] Rethinking Map Features

[Yuri Astrakhan]

P.S. I made a short video on how to add descriptions and translations

https://www.youtube.com/watch?v=rI1NDD4MtC4

On Sun, Aug 4, 2019 at 11:56 AM Yuri Astrakhan 
wrote:

> Joseph, before you click "edit description", change your language at the
> top of the wiki page (make sure you are logged in.  Also, if you change the
> language a few times to the ones you know, e.g. to Indonesian, to Spanish,
> and then to English, I think interface will always offer you to enter
> description in the last few you had picked.
>
> Thanks for adding translations!
>
> On Sun, Aug 4, 2019 at 11:40 AM Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
>
>> You're right, I was a little confused. Almost all the features on Map
>> Features have a wiki page (and those that don't should get a page or
>> more likely be removed), so I understand that they have an OSM
>> wikibase entry, now, and creating the data item isn't an issue.
>>
>> But I still can't figure out how to add description in another language?
>>
>> I tried to get the Indonesian translation by:
>> 1) Open the English wiki page (eg from the link on Map Features in this
>> case)
>> 2) Click on the little pencil to edit the OSM wikibase data item
>> (which I can't see, because I have images disabled, but I just hunt
>> around...)
>> 3) Click on "edit" next to description
>> 4) Click "all entered languages" - wait, how do I add Indonesian?
>> ?
>>
>> Maybe I don't see Indonesian because I'm using a satellite internet
>> connection from Australia and I haven't edited Indonesian before. I
>> try clicking on "Configure" next to "In more languages"
>>
>> I don't see Indonesian there either. So perhaps I have to make a new
>> wikibase entry for my language? Unfortunately I don't see a link to
>> make a new wikibase item.
>>
>> Ok, let's try again with Spanish (Español), that's on the list...
>>
>> I still can't figure it out. How do I add a description in another
>> language?
>>
>> Fortunately I can just make a stub wiki page by:
>>
>> 1) Open the English language page
>> 2) Click on edit
>> 3) Copy the url, add "id:" in front of the page name
>> 4) Copy and paste the ValueDescription / KeyDescription box content
>> 5) Edit the description to Indonesian
>>
>> It looks like that will still be fewer clicks and fewer mouse strokes
>> than editing the OSM wikibase data items, and has the benefit of
>> creating a visible wiki page rather than just editing an obscure data
>> item.
>>
>> Joseph
>>
>> On 8/4/19, Yuri Astrakhan  wrote:
>> > Joseph, could you clarify what you mean by "Map Features entry" ?  If
>> you
>> > only refer to keys/tags/relations/relation roles, than those things are
>> > automatically created -- an editor only needs to translate them.
>> >
>> > I do agree that if we want to store more diverse data items, we need
>> > specialized UI, at least for the initial item creation. Luckily, there
>> is a
>> > large Wikidata community that has already done many such custom UIs. For
>> > example, Wikidata now stores language data (all lexems), and there is a
>> > community-created tool to add such words --
>> > https://tools.wmflabs.org/lexeme-forms/  (I'm not sure if this tool
>> checks
>> > for duplicates, please check first if you want to add new data). There
>> are
>> > many other tools we can model after.  Best thing -- those tools don't
>> have
>> > to be part of the wiki, but can reside anywhere else, and could be in
>> pure
>> > client-side JavaScript.
>> >
>> > On Sun, Aug 4, 2019 at 2:05 AM Joseph Eisenberg
>> > 
>> > wrote:
>> >
>> >> So far, I've found it very difficult to create and edit new wikibase
>> >> entries. I don't think it will be easier for Indonesian mappers to
>> >> create a wikibase entry for every Map Features entry, rather than
>> >> creating a stub page with a description.
>> >>
>> >> The advantage of translating wiki pages for each features is that then
>> >> there is a human-readable page which can be updated and expanded over
>> >> time, and also it's clear where the list of feature descriptions are
>> >> coming from.
>> >>
>> >> If you want everyone to create wikibase entries instead, there needs
>> >> to be a much easier, friendlier interface, available in all languages,
>> >> and I think such a major change should be discussed and be implemented
>> >> only if there is consensus that this would be a clear improvement for
>> >> most language communities.
>>
>> ___
>> 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] Rethinking Map Features

[Yuri Astrakhan]

Joseph, before you click "edit description", change your language at the
top of the wiki page (make sure you are logged in.  Also, if you change the
language a few times to the ones you know, e.g. to Indonesian, to Spanish,
and then to English, I think interface will always offer you to enter
description in the last few you had picked.

Thanks for adding translations!

On Sun, Aug 4, 2019 at 11:40 AM Joseph Eisenberg 
wrote:

> You're right, I was a little confused. Almost all the features on Map
> Features have a wiki page (and those that don't should get a page or
> more likely be removed), so I understand that they have an OSM
> wikibase entry, now, and creating the data item isn't an issue.
>
> But I still can't figure out how to add description in another language?
>
> I tried to get the Indonesian translation by:
> 1) Open the English wiki page (eg from the link on Map Features in this
> case)
> 2) Click on the little pencil to edit the OSM wikibase data item
> (which I can't see, because I have images disabled, but I just hunt
> around...)
> 3) Click on "edit" next to description
> 4) Click "all entered languages" - wait, how do I add Indonesian?
> ?
>
> Maybe I don't see Indonesian because I'm using a satellite internet
> connection from Australia and I haven't edited Indonesian before. I
> try clicking on "Configure" next to "In more languages"
>
> I don't see Indonesian there either. So perhaps I have to make a new
> wikibase entry for my language? Unfortunately I don't see a link to
> make a new wikibase item.
>
> Ok, let's try again with Spanish (Español), that's on the list...
>
> I still can't figure it out. How do I add a description in another
> language?
>
> Fortunately I can just make a stub wiki page by:
>
> 1) Open the English language page
> 2) Click on edit
> 3) Copy the url, add "id:" in front of the page name
> 4) Copy and paste the ValueDescription / KeyDescription box content
> 5) Edit the description to Indonesian
>
> It looks like that will still be fewer clicks and fewer mouse strokes
> than editing the OSM wikibase data items, and has the benefit of
> creating a visible wiki page rather than just editing an obscure data
> item.
>
> Joseph
>
> On 8/4/19, Yuri Astrakhan  wrote:
> > Joseph, could you clarify what you mean by "Map Features entry" ?  If you
> > only refer to keys/tags/relations/relation roles, than those things are
> > automatically created -- an editor only needs to translate them.
> >
> > I do agree that if we want to store more diverse data items, we need
> > specialized UI, at least for the initial item creation. Luckily, there
> is a
> > large Wikidata community that has already done many such custom UIs. For
> > example, Wikidata now stores language data (all lexems), and there is a
> > community-created tool to add such words --
> > https://tools.wmflabs.org/lexeme-forms/  (I'm not sure if this tool
> checks
> > for duplicates, please check first if you want to add new data). There
> are
> > many other tools we can model after.  Best thing -- those tools don't
> have
> > to be part of the wiki, but can reside anywhere else, and could be in
> pure
> > client-side JavaScript.
> >
> > On Sun, Aug 4, 2019 at 2:05 AM Joseph Eisenberg
> > 
> > wrote:
> >
> >> So far, I've found it very difficult to create and edit new wikibase
> >> entries. I don't think it will be easier for Indonesian mappers to
> >> create a wikibase entry for every Map Features entry, rather than
> >> creating a stub page with a description.
> >>
> >> The advantage of translating wiki pages for each features is that then
> >> there is a human-readable page which can be updated and expanded over
> >> time, and also it's clear where the list of feature descriptions are
> >> coming from.
> >>
> >> If you want everyone to create wikibase entries instead, there needs
> >> to be a much easier, friendlier interface, available in all languages,
> >> and I think such a major change should be discussed and be implemented
> >> only if there is consensus that this would be a clear improvement for
> >> most language communities.
>
> ___
> 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] Rethinking Map Features

[Joseph Eisenberg]

You're right, I was a little confused. Almost all the features on Map
Features have a wiki page (and those that don't should get a page or
more likely be removed), so I understand that they have an OSM
wikibase entry, now, and creating the data item isn't an issue.

But I still can't figure out how to add description in another language?

I tried to get the Indonesian translation by:
1) Open the English wiki page (eg from the link on Map Features in this case)
2) Click on the little pencil to edit the OSM wikibase data item
(which I can't see, because I have images disabled, but I just hunt
around...)
3) Click on "edit" next to description
4) Click "all entered languages" - wait, how do I add Indonesian?
?

Maybe I don't see Indonesian because I'm using a satellite internet
connection from Australia and I haven't edited Indonesian before. I
try clicking on "Configure" next to "In more languages"

I don't see Indonesian there either. So perhaps I have to make a new
wikibase entry for my language? Unfortunately I don't see a link to
make a new wikibase item.

Ok, let's try again with Spanish (Español), that's on the list...

I still can't figure it out. How do I add a description in another language?

Fortunately I can just make a stub wiki page by:

1) Open the English language page
2) Click on edit
3) Copy the url, add "id:" in front of the page name
4) Copy and paste the ValueDescription / KeyDescription box content
5) Edit the description to Indonesian

It looks like that will still be fewer clicks and fewer mouse strokes
than editing the OSM wikibase data items, and has the benefit of
creating a visible wiki page rather than just editing an obscure data
item.

Joseph

On 8/4/19, Yuri Astrakhan  wrote:
> Joseph, could you clarify what you mean by "Map Features entry" ?  If you
> only refer to keys/tags/relations/relation roles, than those things are
> automatically created -- an editor only needs to translate them.
>
> I do agree that if we want to store more diverse data items, we need
> specialized UI, at least for the initial item creation. Luckily, there is a
> large Wikidata community that has already done many such custom UIs. For
> example, Wikidata now stores language data (all lexems), and there is a
> community-created tool to add such words --
> https://tools.wmflabs.org/lexeme-forms/  (I'm not sure if this tool checks
> for duplicates, please check first if you want to add new data). There are
> many other tools we can model after.  Best thing -- those tools don't have
> to be part of the wiki, but can reside anywhere else, and could be in pure
> client-side JavaScript.
>
> On Sun, Aug 4, 2019 at 2:05 AM Joseph Eisenberg
> 
> wrote:
>
>> So far, I've found it very difficult to create and edit new wikibase
>> entries. I don't think it will be easier for Indonesian mappers to
>> create a wikibase entry for every Map Features entry, rather than
>> creating a stub page with a description.
>>
>> The advantage of translating wiki pages for each features is that then
>> there is a human-readable page which can be updated and expanded over
>> time, and also it's clear where the list of feature descriptions are
>> coming from.
>>
>> If you want everyone to create wikibase entries instead, there needs
>> to be a much easier, friendlier interface, available in all languages,
>> and I think such a major change should be discussed and be implemented
>> only if there is consensus that this would be a clear improvement for
>> most language communities.

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

Re: [Tagging] Road hierarchy

[Paul Allen]

On Sun, 4 Aug 2019 at 15:51, Florian Lohoff  wrote:

>
> Where do you take this assumption from? I have never heard before that
> residential may not be used for through traffic?
>

Many residential roads are cul-de-sacs.  Dead ends.  Not classed as through
roads because
they don't lead anywhere except the houses that are on them.  Others can be
used as routes
from A to B but there are other routes that are shorter/wider/faster or
some combination of those.
And then there are tertiary (or higher) roads which lead from A to B but
which also have houses
along them.

A cul-de-sac, which many residential roads are, can never be used by
through traffic.  Roads
used by through traffic can have houses on them.  It is useful to make a
distinction in a way
that makes sense.

Of course, the situation is not the same in all countries.  Many towns and
cities in the US are
laid out in a grid plan and most residential roads can carry through
traffic.

So the (unwritten) rule isn't so much that residential roads may not be
used for through
traffic but that if (in normal circumstances) it's used for through traffic
then it's not a
residential road even if there are houses along it.

You could make a case that some roads can be both, but we don't have a way
of tagging
that situation in a way that is widely understood by data consumers, with
routers being the
most important type of data consumer to consider.

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

Re: [Tagging] Multiple values in isced:level

[Paul Allen]

On Sun, 4 Aug 2019 at 15:43, Martin Koppenhoefer 
wrote:

>
> This is also my general understanding although there are situations where
> the meaning can differ, e.g. housenumber = 1-3 can mean either 1;2;3 or 1;3
> (depending on the local numbering scheme for this road).
>

There are several different views on this.  Mine would be 1-3 means 1;2;3
and 1,3 means 1;3.  Oh,
and 1,2,3 is an alternative to 1-3 but more cumbersome.  However, this is
OSM where a foolish
consistency is never the hobgoblin of our little minds.

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

Re: [Tagging] Road hierarchy

[Tomas Straupis]

Well, I would be reluctant to tag the ways leading to this remote
house as unclassified or residential:
https://openmap.lt/#h/17.01/54.19809/24.27953/0/0/
These are public ways/roads, anybody can use them - they are not
private. Yet they are not in the database of Lithuanian road agency,
so they are not managed by road agency.

Here in Lithuania we have a rule for at least ten years that: if you
can see tracks, then it is a track :-) And it corresponds very well to
what we see in topographical maps.

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

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

[Leif Rasmussen]

> If you want a waiting area tag, name it like this.

I *would* agree with this, but public_transport=platform is already quite
established.  Changing tags is worse than having badly named tags.
Leif Rasmussen

On Sun, Aug 4, 2019, 4:40 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 4. Aug 2019, at 15:03, Markus  wrote:
> >
> > Unfortunately it doesn't mean a real platform, but a waiting area (see
> > also Polyglot's message). If it would have meant a real platform,
> > there were no PTv2 tag for the waiting area of a stop without
> > platform, which is the normal situation for bus stops at many places.
>
>
> it is just an excuse to insist on using pt=platform for things that aren’t
> platforms and justify it with saying it means waiting area.
> I don’t think we should define pt=platform for something different than a
> public transport platform, it would be asking for trouble.
> If you want a waiting area tag, name it like this.
>
> 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] Road hierarchy

[Florian Lohoff]

On Sun, Aug 04, 2019 at 04:30:54PM +0200, Martin Koppenhoefer wrote:
> sent from a phone
> > On 4. Aug 2019, at 15:37, Florian Lohoff  wrote:
> > 
> > Their difference is usage. In case of residential its usage is
> > predominantly access to an residential area, whereas the unclassified is
> > for interconnecting residential areas (be it villages).
> 
> for me the access to a residential area is not a residential road, it
> is at least an unclassified road or typically a tertiary road.
> Residential roads are the roads inside the residential area, which are
> not used by through traffic 

Where do you take this assumption from? I have never heard before that
residential may not be used for through traffic?

The opposite is described in highway=residential:

https://wiki.openstreetmap.org/wiki/Tag:highway%3Dresidential

This tag is used for roads accessing or around residential areas.

This is a useful guideline if you are not sure whether to use
residential or unclassified for streets in towns:

residential – street or road generally used for local traffic within
settlement.
unclassified – Unclassified roads typically form the lowest form of
the interconnecting grid network (below highway=tertiary 
roads). Roads
serving for interconnection of small settlements. Use 
residential rather
than unclassified on the road section if there are traffic 
restrictions
(such as slower speed limits) or traffic calming features near 
small
settlements. (See also highway=unclassified.)

So in case of residential usage, reduced speed limit (city boundary?) or
traffic calming one should rather use residential than unclassified.

I agree that living_street is not for through traffic - thats even in
German legalese.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Tagging] Multiple values in isced:level

[Martin Koppenhoefer]

sent from a phone

> On 4. Aug 2019, at 14:14, Andrew Harvey  wrote:
> 
> It could be cultural but I've always understood that the hyphen (-), ie. 1-3 
> would mean it covers 1, 2 and 3, while if you say 1;3 or 1,3 then it would 
> cover 1 and 3 only, excluding two 2.


This is also my general understanding although there are situations where the 
meaning can differ, e.g. housenumber = 1-3 can mean either 1;2;3 or 1;3 
(depending on the local numbering scheme for this road).

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

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

[Martin Koppenhoefer]

sent from a phone

> On 4. Aug 2019, at 15:03, Markus  wrote:
> 
> Unfortunately it doesn't mean a real platform, but a waiting area (see
> also Polyglot's message). If it would have meant a real platform,
> there were no PTv2 tag for the waiting area of a stop without
> platform, which is the normal situation for bus stops at many places.


it is just an excuse to insist on using pt=platform for things that aren’t 
platforms and justify it with saying it means waiting area. 
I don’t think we should define pt=platform for something different than a 
public transport platform, it would be asking for trouble.
If you want a waiting area tag, name it like this.

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

Re: [Tagging] Charging stations: socket::output -- which format for the value?

[Tobias Knerr]

On 31.07.19 09:34, Warin wrote:
> There is no present default unit for power - see
> https://wiki.openstreetmap.org/wiki/Map_Features/Units#Default_units
> Adding a default would be good

Why would it be good to add a default value?

I believe explicit units are generally preferable because they avoid
ambiguity and misunderstandings. With other tags, values without an
explicit unit are already common in the database, so this usage needs to
be documented. But introducing a default for a tag that is generally
used with explicit units doesn't seem useful unless you *want* people to
start omitting the units and rely on the default.

> And the wiki could also state that a space is required between the
> numeric values and the units, if any.

The wiki mentions this as a general rule: "The following units can be
explicitly specified by adding them after the numeric value, separated
by a space". But I agree that this recommendation should also
be repeated on Key:* pages.

Tobias



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

Re: [Tagging] Road hierarchy

[Martin Koppenhoefer]

sent from a phone

> On 4. Aug 2019, at 15:37, Florian Lohoff  wrote:
> 
> Their difference is usage. In case of residential its usage is
> predominantly access to an residential area, whereas the unclassified is
> for interconnecting residential areas (be it villages).


for me the access to a residential area is not a residential road, it is at 
least an unclassified road or typically a tertiary road. Residential roads are 
the roads inside the residential area, which are not used by through traffic 

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

Re: [Tagging] Road hierarchy

[Martin Koppenhoefer]

sent from a phone

> On 4. Aug 2019, at 15:37, Florian Lohoff  wrote:
> 
> A residential is also an unclassified road.


IMHO it is not, as an unclassified road is part of the interconnection grid, 
while a residential road is not 

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

Re: [Tagging] Road hierarchy

[Martin Koppenhoefer]

sent from a phone

> On 4. Aug 2019, at 15:26, Florian Lohoff  wrote:
> 
> - A service road may not carry a name (Because in Germany only public
>  roads get denominated a name).


I don’t think this is a valid conclusion:

- we are not restricting our tagging to official denominations but give 
precedence to on the ground usage

- the service class is further divided into many different classes like 
driveways, alleys, parking aisles, drive through ways, minor generic access 
roads, etc., some may have names, many will usually not carry a name.


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

Re: [Tagging] Road hierarchy

[Martin Koppenhoefer]

sent from a phone

> On 4. Aug 2019, at 11:06, Florian Lohoff  wrote:
> 
> For me a public road
> can not be a service. unclassified is defined as the lowest
> class of public roads.


it is not, it is “at the lowest level of the interconnecting grid network.”, 
which means service roads are not interconnected, while unclassifieds are.

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

Re: [Tagging] Road hierarchy

[Martin Koppenhoefer]

sent from a phone

> On 4. Aug 2019, at 10:46, Tomas Straupis  wrote:
> 
> But what about service/track?


both are lowest classes for motorized vehicles, with a functional difference: 
tracks are for agricultural traffic (or analogously forestry or fishing), while 
service roads are access roads to “something” (restaurant, technical facility, 
etc.), i.e. these are minor roads that do not serve a different purpose than 
accessing a place (otherwise they would be a higher class)

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

Re: [Tagging] Road hierarchy

[Florian Lohoff]

On Sun, Aug 04, 2019 at 11:20:49AM +0100, ael wrote:
> > For me unclassified is the same as residential. The difference is that
> > unclassified is for interconnecting residential areas, and residential
> > has residential traffic. So for me there cant be an unclassified within
> > city boundaries, and as soon as there is predominent residential it
> > cant be a unclassified.
> 
> How have you come to that conclusion? It flatly contradicts the normal
> meaning. Perhaps your local area uses the term "unclassified" in a way
> different from the OSM convention?

A residential is also an unclassified road. It does not have
a classification as a tertiary or primary. So the difference
between an unclassified and a residential is not by their
classification (or lack thereof).

Their difference is usage. In case of residential its usage is
predominantly access to an residential area, whereas the unclassified is
for interconnecting residential areas (be it villages).

This is the exact terminology from:

https://wiki.openstreetmap.org/wiki/Tag:highway%3Dunclassified

"The tag highway=unclassified is used for minor public roads
typically at the lowest level of the interconnecting grid network.
Unclassified roads have lower importance in the road network than
tertiary roads, and are not residential streets or agricultural tracks.
highway=unclassified should be used for roads used for local traffic,
and for roads used to connect other towns, villages or hamlets.
Unclassified roads are considered usable by motor cars. Public
roads of low importance within town and cities that are not residential
may also be highway=unclassified."

So the difference is purely on the usage for residential traffic.

My assumption is that within city boundarys ALL roads carry mostly
residential traffic. One could argue that some roads are carrying
more through traffic than others but where do you draw that line and
do you count traffic when mapping? Its something we as OSM can 
not observe on the ground. Its a statistical matter.

Another indicator for me that neither unclassified nor residential
are of higher priority is the handling in for example OSRM. It
treats both equally in the assumption for travel speed etc.

This is why i make the shortcut in using residential within city
boundarys, and unclassified outside of city boundaries where there
is no residential usage - because everything else is highly disputable
and only provable with traffic analysis and statistics.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Tagging] Road hierarchy

[Florian Lohoff]

On Sun, Aug 04, 2019 at 01:18:13PM +0300, Tomas Straupis wrote:
> 2019-08-04, sk, 12:59 Florian Lohoff rašė:
> > If B is a public road A cant be private property and thus not be
> > a service. If B is a track A can be a service because both
> > of them share the concept of not beeing for the general public.
> >
> > Or vice versa. If you make A a service B cant be a public road.
> 
>   And therefore *track is higher* in the hierarchy than service. Right?

IMHO no - You have a hierarchy of public roads - from
residential/unclassified to motorway. service and track are not
in this hierarchy - they stand outside and carry various restrictions
depending on local regulation and have different purposes.

So a road which is for the general public like a
residential/unclassified must not be only reachable via a track/service.
This would be a breakage in hierarchy. The public road network is always
interconnected and should not build islands which cant be reached by
only using track or service roads. For most of the routers and modes of
transportation these would be hard islands. Same issue arises of
overbroad usage of access=* tagging.

This is why i have multiple QA tasks under these assumptions and German
legalese ...

- A public road may not carry a access=*
  The German legalese does not have a sign which completely forbids
  usage. The most restrictive sign still allows going by foot. 
  So the most restrictive access restriction could be vehicle=no
  (Except for construction - so i exclude highway=construction here)
- A public road may not carry any *=private
  If a public road is restricted to private its not a public road.
  Most likely this is a mistagging of the highway type
- A service road may not carry a name (Because in Germany only public
  roads get denominated a name). So either it has a name or its  
  a service.
- The nearest road to an address should not be a track.
  If the address is for living, the nearest road can not be a track
  as usage for living outweights agricultural usage by orders of
  magnitude. Or better - i search for the nearest legally usable
  road and have a cutoff for errors at arbitrarily chosen ~75meters. 
  Most of the errors i find are long driveways which carry arbitrary
  access tags, or farmyards which are only reachable via tracks.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Tagging] Road hierarchy

[Florian Lohoff]

On Sun, Aug 04, 2019 at 12:25:49PM +0200, Colin Smale wrote:
> On 2019-08-04 11:57, Florian Lohoff wrote:
> 
> > This is why i get to the point "is it a public road" and "a public
> > road cant be service". If we agree on this you can as some zoom scale
> > drop service and track.
> 
> What definition of "public" and "private" are you using here? This is
> another can of worms. 

There is an official road hierarchy where all our roads fit in. These
are for public usage and typically carry an implicit access=yes.

service and track do not belong into this hierarchy. They carry
implicit restrictions which vary from country to country or even
county to county.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

[Markus]

On Sun, 4 Aug 2019 at 13:50, yo paseopor  wrote:
>
> Trains stops in a specific point. Here in Spain they have some sign that 
> says=Cabeza de tren (Head's line) . It is important because when you do a map 
> that can be used by the public transport user, but also the public_transport 
> driver you should have the two positions. OSM data can be infinite and can be 
> professional.

There is a pre-PTv2 tag for this: railway=stop. [1] I'm fine if people
map them, but IMHO they should not be added to the route relations;
they are irrelevant for passenger routing.

[1]: https://wiki.openstreetmap.org/wiki/Tag:railway%3Dstop

> Also you have people saying in this thread for manage in a semiautomatic way 
> the transport lines data is necessary these thow kind of points

It's still unclear to me why the stop positions are required for this.

> Well this is an error. For mi public_transport=platform should be a real 
> platform. It has no sense to have an irreal tag.
> In the stop_position tag you can assure this with platform=yes or platform=no.

Unfortunately it doesn't mean a real platform, but a waiting area (see
also Polyglot's message). If it would have meant a real platform,
there were no PTv2 tag for the waiting area of a stop without
platform, which is the normal situation for bus stops at many places.

Markus

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

Re: [Tagging] Multiple values in isced:level

[Jo]

Use semicolons, for a range use 4;5;6. Be explicit and keep with the
standard value separator.

On Sun, Aug 4, 2019 at 2:17 PM Andrew Harvey 
wrote:

> It could be cultural but I've always understood that the hyphen (-), ie.
> 1-3 would mean it covers 1, 2 and 3, while if you say 1;3 or 1,3 then it
> would cover 1 and 3 only, excluding two 2.
>
> So I think it depends, if you want a range use "-" if you don't want a
> range use a ";" or ",".
>
> I've tagged with isced:level many times and have commonly used a "-" to
> indicate a range, eg. 1-2.
>
> On Sun, 4 Aug 2019 at 19:29, Lanxana .  wrote:
>
>> Hi!
>> I would like to know how to indicate that a school offers several
>> educational levels. I've been seeing the isced: level tag, which is that I
>> think to use, but I have a question about how to separate multiple values.
>>
>> I have looked in taginfo and approximately in 15000 cases the semicolon
>> (;) is used, in 3000 the comma (,) and in 1000 cases the hyphen (-). It
>> would seem therefore that the general criteria is to use the semicolon.
>>
>> It really is that? Is there no risk of causing errors when converting
>> data to another format?
>>
>> Another option that I had valued, and of which I have not found use, is
>> to add the level in the label itself, thus being:
>>
>> isced: level: 1 = yes + isced: level: 2 = yes, for a center that offers
>> levels 1 and 2.
>>
>> What's your opinion?
>>
>> Thanks!
>> ___
>> 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] Was public_transport=platform intended to always be combined with highway=bus_stop?

[Jo]

> highway=platform and/or railway=platform are needed, because
>> public_transport=platform doesn't mean a platform, but a waiting area.
>> And a waiting areas doesn't need to be a platform: some waiting areas
>> are just poles or signs beside the road [1], others are located on the
>> sidewalk [2]. Besides, there are platforms that aren't operated
>> (anymore) and therefore aren't waiting areas, that is
>> public_transport=platform's, anymore.
>>
>
> Well this is an error. For mi public_transport=platform should be a real
> platform. It has no sense to have an irreal tag.
> In the stop_position tag you can assure this with platform=yes or
> platform=no.
>

When the "new" public_transport tag came along, I asked how should I tag
the nodes beside the street that represent the bus stops? Regardless of
whether a platform is present. And the answer was to use
public_transport=platform. So no, this is not an error.

For more than half a decade I have been trying to convince the people
responsible for the rendering of the main map to render nodes with
public_transport=platform + bus=yes like highway=bus_stop.

It became clear by now that this will NEVER happen.

Thus public_transport=platform / bus=yes to replace highway=bus_stop became
unnecessary. I think I'm going to remove those 2 tags everywhere in
Belgium, when I review those 7 bus stops, this time with help of
Mapillary images for the positioning. They became pointless.

But until now, I was using them. I was also using highway=platform to
indicate the real bus platforms and railway=platform for the tram stops.
Either in combination with public_transport=platform, or not. What I was
not doing is duplicating information on these platform ways, or on the
occasional stop_position node I was adding. And they also don't go into the
route relations.

1 object per stop in the route relations should be enough. I'm using the
nodes that represent the bus stops / passenger waiting areas next to the
highways for the purpose of representing the stops along the itineraries.
Works great! And isn't overly complicated or needing a lot of unnecessary
maintenance.

We need the simplest way of doing things that works.

When Uber starts flying, we'll tackle that problem then. No need for a
future proof public_transport scheme for that purpose.

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

Re: [Tagging] Multiple values in isced:level

[Andrew Harvey]

It could be cultural but I've always understood that the hyphen (-), ie.
1-3 would mean it covers 1, 2 and 3, while if you say 1;3 or 1,3 then it
would cover 1 and 3 only, excluding two 2.

So I think it depends, if you want a range use "-" if you don't want a
range use a ";" or ",".

I've tagged with isced:level many times and have commonly used a "-" to
indicate a range, eg. 1-2.

On Sun, 4 Aug 2019 at 19:29, Lanxana .  wrote:

> Hi!
> I would like to know how to indicate that a school offers several
> educational levels. I've been seeing the isced: level tag, which is that I
> think to use, but I have a question about how to separate multiple values.
>
> I have looked in taginfo and approximately in 15000 cases the semicolon
> (;) is used, in 3000 the comma (,) and in 1000 cases the hyphen (-). It
> would seem therefore that the general criteria is to use the semicolon.
>
> It really is that? Is there no risk of causing errors when converting data
> to another format?
>
> Another option that I had valued, and of which I have not found use, is to
> add the level in the label itself, thus being:
>
> isced: level: 1 = yes + isced: level: 2 = yes, for a center that offers
> levels 1 and 2.
>
> What's your opinion?
>
> Thanks!
> ___
> 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] Multiple values in isced:level

[Paul Allen]

On Sun, 4 Aug 2019 at 10:29, Lanxana .  wrote:

>
> I have looked in taginfo and approximately in 15000 cases the semicolon
> (;) is used, in 3000 the comma (,) and in 1000 cases the hyphen (-). It
> would seem therefore that the general criteria is to use the semicolon.
>

See https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator

One thing that page doesn't explicitly mention is that the semi-colon is a
problem in URLs because
it can be a valid, meaningful character in some URLs.

It really is that? Is there no risk of causing errors when converting data
> to another format?
>

See link above.

Another option that I had valued, and of which I have not found use, is to
> add the level in the label itself, thus being:
>
> isced: level: 1 = yes + isced: level: 2 = yes, for a center that offers
> levels 1 and 2.
>

See link above.

What's your opinion?
>

Ask any two people on this list their opinion on any matter and you will
get THREE opinions.
At least.

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

Re: [Tagging] Was public_transport=platform intended to always be combined with highway=bus_stop?

[yo paseopor]

On Sat, Aug 3, 2019 at 9:24 PM Markus  wrote:

> Hi!
>
> On Sat, 3 Aug 2019 at 20:38, yo paseopor  wrote:
> >
> > We need a new way of following the scheme. I think all the features are
> needed: stop positions, platforms and stop area. [...]
>
> Could you please give me an example where stop positions are needed?
>

Trains stops in a specific point. Here in Spain they have some sign that
says=Cabeza de tren (Head's line) . It is important because when you do a
map that can be used by the public transport user, but also the
public_transport driver you should have the two positions. OSM data can be
infinite and can be professional. Also you have people saying in this
thread for manage in a semiautomatic way the transport lines data is
necessary these thow kind of points

> In my experience, mapping stop positions and stop areas is only very
> time-consuming (without a benefit), but also makes maintaining the
> routes harder. (Of course, stop areas are helpful at stations,
> especially at subway stations, in order connect the entrances to the
> station.)
>
> > We should deprecate all kind of stuff for public transport who does not
> not have the public transport tag itself. Because a platform has no sense
> if is not for public_transport. No more highway=platform, railway=platform,
> seaway=platform, river=platform.
>
> Apart from the fact that seaway=platform and river=platform don't
> exist,

Sure? Is not there public_transport by sea, by river, by lake? Will be not
ever?
Public transport scheme is a good scheme for present but also for the
future. When you will have Uber flying cabs which scheme will you will have
we invent in a few years? With this proposal only one: flying_cab=yes



> highway=platform and/or railway=platform are needed, because
> public_transport=platform doesn't mean a platform, but a waiting area.
> And a waiting areas doesn't need to be a platform: some waiting areas
> are just poles or signs beside the road [1], others are located on the
> sidewalk [2]. Besides, there are platforms that aren't operated
> (anymore) and therefore aren't waiting areas, that is
> public_transport=platform's, anymore.
>

Well this is an error. For mi public_transport=platform should be a real
platform. It has no sense to have an irreal tag.
In the stop_position tag you can assure this with platform=yes or
platform=no.

>
> [1]: https://www.mapillary.com/map/im/WzQODhqrCxxBLTYj2YJ-8g
> [2]: https://www.mapillary.com/map/im/9HJR2HmtsEPsPVDV682kZQ
>
> Regards
>
> Markus
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


Salut i transport públic (health and public transport)
yopaseopor
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rethinking Map Features

[Andrew Hain]

How would you stop the bot from going down and protect against whoever runs it 
leaving OSM?

--
Andrew

From: Yuri Astrakhan 
Sent: 03 August 2019 23:06
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Rethinking Map Features

The biggest issue with using Lua/Server side scripting with large lists is that 
every single data item used on a wiki page requires a separate SQL query (or 
even multiple ones), due to how mediawiki + wikibase is implemented.  On the 
other hand, relying on TagInfo has some shortcomings - TagInfo does not (yet) 
understand data items, relying on its own wiki page parser, it is very fixed in 
a way it can present information, and every wiki page view also uses makes 1 or 
more external call to taginfo (higher chance of something going down).

There is a popular middle ground that can solve it for us -- very flexible, 
highly performant, uses a common data source (data items), and relies on a 
single system.  Essentially it is a bot-updated wiki markup:

* an editor adds a special template at the top of a wiki page, where they 
specify a SPARQL query for the data they want - i.e. "find all 
label+description+image of data items, whose type is a 'tag' and whose key is 
'denomination'".  A bot would run that query on occasion (e.g. once a day), and 
append query results to that same page after the template.  Thus, the result 
becomes a regular wiki markup, without any significant server costs.  See 
https://www.wikidata.org/wiki/Template:Wikidata_list

The PROs:
* The bot can run at any moment, by anyone, to update the data
* In the worst case of a bot completely dying, wiki markup could be edited by 
hand until the bot is fixed
* very flexible - a complex query could get any data needed for the output, and 
the output is templated to show in any kind of a list/table format.

CONs:
* every list update is essentially a wiki page edit, slowly increasing history. 
This is not that big of a deal because size wise the growth is small and has 
very little performance impact, plus it makes it possible to track changes with 
time.

On Sat, Aug 3, 2019 at 5:25 PM Andrew Hain 
mailto:andrewhain...@hotmail.co.uk>> wrote:

Now the wiki has data items and scripting in Lua I have been wondering whether 
they are a useful alternative to Taginfo-driven lists.

Advantages of server scripts:

  1.  Descriptions can be generated from data items, tharefore they can be in a 
language where there is no long form documentation for the key. This resolves 
the issues that have limited use of taglists in languages other than English 
because descriptions can be rolled out quickly and some can be copied from the 
old map features templates.
  2.  Tables at the top of pages are visible immediately,
  3.  A successful connection to 
tagindo.openstreetmap.org is unnecessary.

Advantages of taglists driven by Taginfo:

  1.  The technology aleady exists and can be rolled out.
  2.  Separate scripts avoid overloading the server (Map Features in Polish, 
Ukrainian and Japanese hits wiki limits).
  3.  The web scripts are free-standing and can be hosted on another website 
outside the wiki,

(crossposted from 
https://wiki.openstreetmap.org/wiki/Talk:Taginfo/Taglists#Server_scripts_as_alternative_taglists)

--
Andrew
Talk:Taginfo/Taglists - OpenStreetMap 
Wiki
Languages. This is a very cool feature! One question: Could the template get 
the langugage automatically? I know this is done on some templates (e.g. 
Template:Tag).-- Jojo4u 17:20, 20 August 2015 (UTC) . I am not a template 
wizard.
wiki.openstreetmap.org


From: Joseph Eisenberg 
mailto:joseph.eisenb...@gmail.com>>
Sent: 02 August 2019 14:22
To: Tag discussion, strategy and related tools 
mailto:tagging@openstreetmap.org>>
Subject: Re: [Tagging] Rethinking Map Features

Andrew,

I now think it is a good idea to switch to taglists for all of the Map
Feature page templates. It will make it much easier to keep the pages
consistent and to a reasonable length if all of the descriptions are
pulled from the wiki pages directly (just as is done for descriptions
used by Taginfo).

This just means that any deprecated or discouraged tags which are
currently "strikethrough" on Map Features will need something in the
description that mentions that they are discouraged. This is a good
idea anyway, so that the documentation is consistent.

Joseph

On 7/7/19, Andrew Hain 
mailto:andrewhain...@hotmail.co.uk>> wrote:
> I have been working on a scheme to improve the cross-language quality of Map
> Features.
> [https://wiki.openstreetmap.org/wiki/Talk:Map_Features#Reimagining_Map_Features]
>
> Of course the page may deserve a bigger or deeper rethink.
>
> --
> Andrew
> Talk:Map Features - OpenStreetMap
> 

Re: [Tagging] Road hierarchy

[Colin Smale]

On 2019-08-04 11:57, Florian Lohoff wrote:

> This is why i get to the point "is it a public road" and "a public
> road cant be service". If we agree on this you can as some zoom scale
> drop service and track.

What definition of "public" and "private" are you using here? This is
another can of worms. 

No two maps are the same. At the end of the day, a cartographer will
want control over their definition of "relative importance", based on
objective things like official classification, width, lanes, ownership,
access, traffic density, usage class (residential access etc). If we
wilfully manipulate the tagging to facilitate a particular definition of
"relative importance" we are breaking one of our own golden rules of
course. So let's stick to objective quantities if at all possible. Then
the "hierarchy" discussion is deferred to the cartographer in the
consumption phase, instead of the contributor in the data collection
phase.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Road hierarchy

[ael]

On Sun, Aug 04, 2019 at 10:30:49AM +0200, Florian Lohoff wrote:
> On Sun, Aug 04, 2019 at 09:35:41AM +0300, Tomas Straupis wrote:
> > Hello
> > 
> >   Road hierarchy is needed for a number of things:
> >   * deciding which classes of roads to display on different scales in a map
> >   * performing road network validation
> >   * other tasks (f.e. typification of buildings - orientation)
> > 
> >   Hierarchy would be different in different context: motorcar, bicycle,
> > pedestrian etc. For the time being I'm only asking about motorcars.
> > 
> >   There is non written (or I could not find in wiki) or "de facto"
> > hierarchy:
> >   * motorway
> >   * trunk
> >   * primary
> >   * secondary
> >   * tertiary
> >   * unclassified
> >   * residential
> >   * living_street
> >   In some regions unclassified has a higher position in hierarchy, in other
> > regions unclassified, residential and living_street have the same position.
> > This is fine for the time being.
> >   I'm also intentionally skipping _link classes.
> 
+1

> For me unclassified is the same as residential. The difference is that
> unclassified is for interconnecting residential areas, and residential
> has residential traffic. So for me there cant be an unclassified within
> city boundaries, and as soon as there is predominent residential it
> cant be a unclassified.

How have you come to that conclusion? It flatly contradicts the normal
meaning. Perhaps your local area uses the term "unclassified" in a way
different from the OSM convention?

ael


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

Re: [Tagging] Road hierarchy

[Tomas Straupis]

2019-08-04, sk, 12:59 Florian Lohoff rašė:
> If B is a public road A cant be private property and thus not be
> a service. If B is a track A can be a service because both
> of them share the concept of not beeing for the general public.
>
> Or vice versa. If you make A a service B cant be a public road.

  And therefore *track is higher* in the hierarchy than service. Right?

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

Re: [Tagging] Road hierarchy

[Florian Lohoff]

On Sun, Aug 04, 2019 at 12:46:05PM +0300, Tomas Straupis wrote:
> Now I would like to skip road C at small scale, but leave A, because I
> want to leave B.
> 
> Can we agree on some scheme to tag this (do data augmentation), so
> that less people doing cartography stuff have to resort to heavy
> generalisation operation such as road pruning?

When you honestly look at roads something like a correct hierarchy
always ressembles.

This is why i get to the point "is it a public road" and "a public
road cant be service". If we agree on this you can as some zoom scale
drop service and track.

Because a public road does not branch of a private road. There is
your hierarchy.

So getting back to your example:

R
R
RAAA
R  A
R
R
R
R

If B is a public road A cant be private property and thus not be
a service. If B is a track A can be a service because both
of them share the concept of not beeing for the general public.

Or vice versa. If you make A a service B cant be a public road.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Tagging] Road hierarchy

[Florian Lohoff]

On Sun, Aug 04, 2019 at 12:19:52PM +0300, Tomas Straupis wrote:
> Let's say we have a residential road R. Going out of this residential road
> there is a way A into the neighbouring residential area (say 50m length).
> Out of that way A there is anower way B leading into the fields/forest
> which lies outside of the residential area. B way is long enough and
> significant, say leading to some locally significant object (ruins, tree,
> lake).
> 
> R
> R
> RAAA
> R  A
> R

> What could be correct:
> a) A - service (service=???), B - track (tracktype=???)
> b) A - track grade1 B - track grade>1
> c) others

Is A a public named road? Make is residential. Is it a driveway
just for a single home? Make it service.

Is B predominantly for agricultural purposes? Make it track. Are
there more visitors to the ruins and its a public road? Make
it unclassified. Otherwise people cant navigate their POI.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Tagging] Road hierarchy

[Tomas Straupis]

All right, let's make it more detailed and more extended.

R
R
RAAA
R  A
R
R
R
R

Now A and C are ways leading into the inner territory of residential
building(s). But A has another important road B getting out of it, and
C does not. Which means A has through traffic while C does not. But
all of them are very minor ways visible as two tracks on the ground.
Way C is used say twice in a week.

Now I would like to skip road C at small scale, but leave A, because I
want to leave B.

Can we agree on some scheme to tag this (do data augmentation), so
that less people doing cartography stuff have to resort to heavy
generalisation operation such as road pruning?

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

[Tagging] Multiple values in isced:level

[Lanxana .]

Hi!
I would like to know how to indicate that a school offers several
educational levels. I've been seeing the isced: level tag, which is that I
think to use, but I have a question about how to separate multiple values.

I have looked in taginfo and approximately in 15000 cases the semicolon (;)
is used, in 3000 the comma (,) and in 1000 cases the hyphen (-). It would
seem therefore that the general criteria is to use the semicolon.

It really is that? Is there no risk of causing errors when converting data
to another format?

Another option that I had valued, and of which I have not found use, is to
add the level in the label itself, thus being:

isced: level: 1 = yes + isced: level: 2 = yes, for a center that offers
levels 1 and 2.

What's your opinion?

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

Re: [Tagging] Road hierarchy

[Tomas Straupis]

Let's say we have a residential road R. Going out of this residential road
there is a way A into the neighbouring residential area (say 50m length).
Out of that way A there is anower way B leading into the fields/forest
which lies outside of the residential area. B way is long enough and
significant, say leading to some locally significant object (ruins, tree,
lake).

R
R
RAAA
R  A
R


What could be correct:
a) A - service (service=???), B - track (tracktype=???)
b) A - track grade1 B - track grade>1
c) others
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Road hierarchy

[Warin]

On 04/08/19 19:08, Tomas Straupis wrote:

2019-08-04, sk, 11:56 Erkin Alp Güney rašė:

Paved: service unpaved:track

   service could always be paved and unpaved.
   track used to be always unpaved, but somewhere somehow tracktype1
became paved :-)


I have a number of tracks around me. Some sections of them are paved to stop 
soil erosion. They are still tracks even if paved.

There are a number of main highways that are unpaved too, over long distances.

The surface of the road and how wide it is does not determine its importance to 
the road network and the local community.
The surface and width may impede or help transportation, but they don't change 
the necessity of using the roads.


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

Re: [Tagging] Road hierarchy

[Florian Lohoff]

On Sun, Aug 04, 2019 at 11:55:08AM +0300, Erkin Alp Güney wrote:
> Paved: service unpaved:track

So half of the highways in African countries are tracks?

IIRC osm does tag highway class by usage not by construction or
physical attributes.

So there is a perfect possibility that large stretches of primary roads
in Madagascar should carry a surface=dirt - So yes - highway=primary
surface=dirt is a pretty likely combination.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Tagging] Road hierarchy

[Tomas Straupis]

2019-08-04, sk, 11:56 Erkin Alp Güney rašė:
> Paved: service unpaved:track

  service could always be paved and unpaved.
  track used to be always unpaved, but somewhere somehow tracktype1
became paved :-)

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

Re: [Tagging] Road hierarchy

[Florian Lohoff]

Hi,

On Sun, Aug 04, 2019 at 11:46:26AM +0300, Tomas Straupis wrote:
> 2019-08-04, sk, 11:32 Florian Lohoff rašė:
> > For me unclassified is the same as residential. <...>
> 
>   Ok, so unclassified vs residential is regionally defined, as I wrote.
> 
>   But what about service/track?

Same dispute. I am one of the track opponents for years. I live in
the outback myself and i try to stop people tagging every road beyond
city limits as track.

A track is predominently for agricultural use. As soon as there
are people living there are predominently other uses than agricultural.

So the driveway to a farmyard can not be a track. 

I once made the claim its not a track if:

- The postal service uses it or
- The garbage truck uses it or
- The school bus uses it

And all of that is true if people are living there. The problem is
that tracks are not even considered in most routing/navigational
software so a lot of my neighbours would not be reachable if tagging
outback roads as track would hold up. 

So track is when there are no buildings or only a field barn.


Service is for me another complicated beast. For me a public road
can not be a service. unclassified is defined as the lowest
class of public roads. Service is defined as roads on industrial areas
etc.

So for Germany it cant be a service if:

- its of public use or
- it has a name (Only public roads get demoniated a name)

So i only tag roads on parking, driveway or industrial complexes
etc as service. I consider service roads beeing treated as
"access" destination and not for public use.

This is the reason why i dont think tagging every driveway as
access=private is a good thing to do. That causes all navigational
software to exclude these road snippets completely from their index. Now
you have private driveways up to multiple kilometers. When you now
navigate to an address you get told "You have reached your destination"
while beeing on the main road some multiple kilometers away not even
in visible contact to the building or the driveway. You might
even be on the wrong main road as mapping of addresses to the point
on the road network to navigate to is a minimum distance decision.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Tagging] Road hierarchy

[Erkin Alp Güney]

Paved: service unpaved:track

4 Ağu 2019 Paz 11:47 tarihinde Tomas Straupis 
şunu yazdı:

> 2019-08-04, sk, 11:32 Florian Lohoff rašė:
>
>   Ok, so unclassified vs residential is regionally defined, as I wrote.
>
>   But what about service/track?
>
> ___
> 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] Road hierarchy

[Tomas Straupis]

2019-08-04, sk, 11:32 Florian Lohoff rašė:
> For me unclassified is the same as residential. <...>

  Ok, so unclassified vs residential is regionally defined, as I wrote.

  But what about service/track?

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

Re: [Tagging] Road hierarchy

[Florian Lohoff]

On Sun, Aug 04, 2019 at 09:35:41AM +0300, Tomas Straupis wrote:
> Hello
> 
>   Road hierarchy is needed for a number of things:
>   * deciding which classes of roads to display on different scales in a map
>   * performing road network validation
>   * other tasks (f.e. typification of buildings - orientation)
> 
>   Hierarchy would be different in different context: motorcar, bicycle,
> pedestrian etc. For the time being I'm only asking about motorcars.
> 
>   There is non written (or I could not find in wiki) or "de facto"
> hierarchy:
>   * motorway
>   * trunk
>   * primary
>   * secondary
>   * tertiary
>   * unclassified
>   * residential
>   * living_street
>   In some regions unclassified has a higher position in hierarchy, in other
> regions unclassified, residential and living_street have the same position.
> This is fine for the time being.
>   I'm also intentionally skipping _link classes.

For me unclassified is the same as residential. The difference is that
unclassified is for interconnecting residential areas, and residential
has residential traffic. So for me there cant be an unclassified within
city boundaries, and as soon as there is predominent residential it
cant be a unclassified.

So my guideline was:

Unclassified
- Public road
- Not classified
- Outside of city Boundary
- No predominant housing

Residential
- Public road
- Not classified
- Housing


This has been a constant argument on different mailinglist for multiple
years. Defacto handle routing engines those two identical so retagging
a residential to unclassified does not make them "quicker" in terms
of routability.

So - YMMV - And its easy to start another argument here ;)

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Tagging] Road hierarchy

[Tomas Straupis]

> Personally, I'd have put residential / living together above unclassified

  Interesting. Unclassified was always (more than 10 years) defined
for "through traffic" which puts it a higher in a hierarchy. From what
I understand it was always in the group of primary/secondary/tertiary
just the one which does not have an official classification - thus
"unclassified".

> Once again, personally service before track, maybe further split that 
> highway=service by itself is higher that the "types" of service road 
> (driveway, parking aisle etc)

  This way of interpreting service would make it impossible to
identify if missing service=* tag means:
  1. missing tag/information
  2. specified higher priority service road
  For example if you have service=driveway and want to make it higher
priority service road, you should change service value to something
else rather than remove service=* key.

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

Re: [Tagging] Road hierarchy

[Graeme Fitzpatrick]

On Sun, 4 Aug 2019 at 16:37, Tomas Straupis  wrote:

>
>   There is non written (or I could not find in wiki) or "de facto"
> hierarchy:
>   * motorway
>   * trunk
>   * primary
>   * secondary
>   * tertiary
>   * unclassified
>   * residential
>   * living_street
>   In some regions unclassified has a higher position in hierarchy, in
> other regions unclassified, residential and living_street have the same
> position. This is fine for the time being.
>

Personally, I'd have put residential / living together above unclassified


>My question is about what goes further:
>   track / service
>   Which of them is higher?
>   Does additional tags influence this? For example does adding
> service=driveway reduce position in hierarchy of service road? Does any
> value of tracktype change position of track road?
>

Once again, personally service before track, maybe further split that
highway=service by itself is higher that the "types" of service road
(driveway, parking aisle etc)

Thanks

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

Re: [Tagging] Rethinking Map Features

[Yuri Astrakhan]

Joseph, could you clarify what you mean by "Map Features entry" ?  If you
only refer to keys/tags/relations/relation roles, than those things are
automatically created -- an editor only needs to translate them.

I do agree that if we want to store more diverse data items, we need
specialized UI, at least for the initial item creation. Luckily, there is a
large Wikidata community that has already done many such custom UIs. For
example, Wikidata now stores language data (all lexems), and there is a
community-created tool to add such words --
https://tools.wmflabs.org/lexeme-forms/  (I'm not sure if this tool checks
for duplicates, please check first if you want to add new data). There are
many other tools we can model after.  Best thing -- those tools don't have
to be part of the wiki, but can reside anywhere else, and could be in pure
client-side JavaScript.

On Sun, Aug 4, 2019 at 2:05 AM Joseph Eisenberg 
wrote:

> So far, I've found it very difficult to create and edit new wikibase
> entries. I don't think it will be easier for Indonesian mappers to
> create a wikibase entry for every Map Features entry, rather than
> creating a stub page with a description.
>
> The advantage of translating wiki pages for each features is that then
> there is a human-readable page which can be updated and expanded over
> time, and also it's clear where the list of feature descriptions are
> coming from.
>
> If you want everyone to create wikibase entries instead, there needs
> to be a much easier, friendlier interface, available in all languages,
> and I think such a major change should be discussed and be implemented
> only if there is consensus that this would be a clear improvement for
> most language communities.
>
> On 8/4/19, Yuri Astrakhan  wrote:
> > The biggest issue with using Lua/Server side scripting with large lists
> is
> > that every single data item used on a wiki page requires a separate SQL
> > query (or even multiple ones), due to how mediawiki + wikibase is
> > implemented.  On the other hand, relying on TagInfo has some
> shortcomings -
> > TagInfo does not (yet) understand data items, relying on its own wiki
> page
> > parser, it is very fixed in a way it can present information, and every
> > wiki page view also uses makes 1 or more external call to taginfo (higher
> > chance of something going down).
> >
> > There is a popular middle ground that can solve it for us -- very
> flexible,
> > highly performant, uses a common data source (data items), and relies on
> a
> > single system.  Essentially it is a bot-updated wiki markup:
> >
> > * an editor adds a special template at the top of a wiki page, where they
> > specify a SPARQL query for the data they want - i.e. "find all
> > label+description+image of data items, whose type is a 'tag' and whose
> key
> > is 'denomination'".  A bot would run that query on occasion (e.g. once a
> > day), and append query results to that same page after the template.
> Thus,
> > the result becomes a regular wiki markup, without any significant server
> > costs.  See https://www.wikidata.org/wiki/Template:Wikidata_list
> >
> > The PROs:
> > * The bot can run at any moment, by anyone, to update the data
> > * In the worst case of a bot completely dying, wiki markup could be
> edited
> > by hand until the bot is fixed
> > * very flexible - a complex query could get any data needed for the
> output,
> > and the output is templated to show in any kind of a list/table format.
> >
> > CONs:
> > * every list update is essentially a wiki page edit, slowly increasing
> > history. This is not that big of a deal because size wise the growth is
> > small and has very little performance impact, plus it makes it possible
> to
> > track changes with time.
> >
> > On Sat, Aug 3, 2019 at 5:25 PM Andrew Hain 
> > wrote:
> >
> >> Now the wiki has data items and scripting in Lua I have been wondering
> >> whether they are a useful alternative to Taginfo-driven lists.
> >>
> >> Advantages of server scripts:
> >>
> >>1. Descriptions can be generated from data items, tharefore they can
> >>be in a language where there is no long form documentation for the
> >> key.
> >>This resolves the issues that have limited use of taglists in
> >> languages
> >>other than English because descriptions can be rolled out quickly and
> >> some
> >>can be copied from the old map features templates.
> >>2. Tables at the top of pages are visible immediately,
> >>3. A successful connection to tagindo.openstreetmap.org is
> >> unnecessary.
> >>
> >> Advantages of taglists driven by Taginfo:
> >>
> >>1. The technology aleady exists and can be rolled out.
> >>2. Separate scripts avoid overloading the server (Map Features in
> >>Polish, Ukrainian and Japanese hits wiki limits).
> >>3. The web scripts are free-standing and can be hosted on another
> >>website outside the wiki,
> >>
> >> (crossposted from
> >>
> 

[Tagging] Road hierarchy

[Tomas Straupis]

Hello

  Road hierarchy is needed for a number of things:
  * deciding which classes of roads to display on different scales in a map
  * performing road network validation
  * other tasks (f.e. typification of buildings - orientation)

  Hierarchy would be different in different context: motorcar, bicycle,
pedestrian etc. For the time being I'm only asking about motorcars.

  There is non written (or I could not find in wiki) or "de facto"
hierarchy:
  * motorway
  * trunk
  * primary
  * secondary
  * tertiary
  * unclassified
  * residential
  * living_street
  In some regions unclassified has a higher position in hierarchy, in other
regions unclassified, residential and living_street have the same position.
This is fine for the time being.
  I'm also intentionally skipping _link classes.

  My question is about what goes further:
  track / service
  Which of them is higher?
  Does additional tags influence this? For example does adding
service=driveway reduce position in hierarchy of service road? Does any
value of tracktype change position of track road?

  And in general, is there a point of agreeing on this globally or it will
stay regional anyway?

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

Re: [Tagging] Rethinking Map Features

[Joseph Eisenberg]

So far, I've found it very difficult to create and edit new wikibase
entries. I don't think it will be easier for Indonesian mappers to
create a wikibase entry for every Map Features entry, rather than
creating a stub page with a description.

The advantage of translating wiki pages for each features is that then
there is a human-readable page which can be updated and expanded over
time, and also it's clear where the list of feature descriptions are
coming from.

If you want everyone to create wikibase entries instead, there needs
to be a much easier, friendlier interface, available in all languages,
and I think such a major change should be discussed and be implemented
only if there is consensus that this would be a clear improvement for
most language communities.

On 8/4/19, Yuri Astrakhan  wrote:
> The biggest issue with using Lua/Server side scripting with large lists is
> that every single data item used on a wiki page requires a separate SQL
> query (or even multiple ones), due to how mediawiki + wikibase is
> implemented.  On the other hand, relying on TagInfo has some shortcomings -
> TagInfo does not (yet) understand data items, relying on its own wiki page
> parser, it is very fixed in a way it can present information, and every
> wiki page view also uses makes 1 or more external call to taginfo (higher
> chance of something going down).
>
> There is a popular middle ground that can solve it for us -- very flexible,
> highly performant, uses a common data source (data items), and relies on a
> single system.  Essentially it is a bot-updated wiki markup:
>
> * an editor adds a special template at the top of a wiki page, where they
> specify a SPARQL query for the data they want - i.e. "find all
> label+description+image of data items, whose type is a 'tag' and whose key
> is 'denomination'".  A bot would run that query on occasion (e.g. once a
> day), and append query results to that same page after the template.  Thus,
> the result becomes a regular wiki markup, without any significant server
> costs.  See https://www.wikidata.org/wiki/Template:Wikidata_list
>
> The PROs:
> * The bot can run at any moment, by anyone, to update the data
> * In the worst case of a bot completely dying, wiki markup could be edited
> by hand until the bot is fixed
> * very flexible - a complex query could get any data needed for the output,
> and the output is templated to show in any kind of a list/table format.
>
> CONs:
> * every list update is essentially a wiki page edit, slowly increasing
> history. This is not that big of a deal because size wise the growth is
> small and has very little performance impact, plus it makes it possible to
> track changes with time.
>
> On Sat, Aug 3, 2019 at 5:25 PM Andrew Hain 
> wrote:
>
>> Now the wiki has data items and scripting in Lua I have been wondering
>> whether they are a useful alternative to Taginfo-driven lists.
>>
>> Advantages of server scripts:
>>
>>1. Descriptions can be generated from data items, tharefore they can
>>be in a language where there is no long form documentation for the
>> key.
>>This resolves the issues that have limited use of taglists in
>> languages
>>other than English because descriptions can be rolled out quickly and
>> some
>>can be copied from the old map features templates.
>>2. Tables at the top of pages are visible immediately,
>>3. A successful connection to tagindo.openstreetmap.org is
>> unnecessary.
>>
>> Advantages of taglists driven by Taginfo:
>>
>>1. The technology aleady exists and can be rolled out.
>>2. Separate scripts avoid overloading the server (Map Features in
>>Polish, Ukrainian and Japanese hits wiki limits).
>>3. The web scripts are free-standing and can be hosted on another
>>website outside the wiki,
>>
>> (crossposted from
>> https://wiki.openstreetmap.org/wiki/Talk:Taginfo/Taglists#Server_scripts_as_alternative_taglists
>> )
>>
>> --
>> Andrew
>> Talk:Taginfo/Taglists - OpenStreetMap Wiki
>> 
>> Languages. This is a very cool feature! One question: Could the template
>> get the langugage automatically? I know this is done on some templates
>> (e.g. Template:Tag).-- Jojo4u 17:20, 20 August 2015 (UTC) . I am not a
>> template wizard.
>> wiki.openstreetmap.org
>>
>> --
>> *From:* Joseph Eisenberg 
>> *Sent:* 02 August 2019 14:22
>> *To:* Tag discussion, strategy and related tools <
>> tagging@openstreetmap.org>
>> *Subject:* Re: [Tagging] Rethinking Map Features
>>
>> Andrew,
>>
>> I now think it is a good idea to switch to taglists for all of the Map
>> Feature page templates. It will make it much easier to keep the pages
>> consistent and to a reasonable length if all of the descriptions are
>> pulled from the wiki pages directly (just as is done for descriptions
>> used by Taginfo).
>>
>> This just means that any deprecated or discouraged