Re: [Tagging] public_transport=platform rendering on osm-carto

[Jo]

The thing is, when PTv2 was voted, I asked what to do with the bus stop
nodes next to the way. The answer was put public_transport=platform on
those NODES. In fact they rather represent a pole with a flag on it. But
for some bus stops, there is nothing physical present. The bus stops there
and both passengers and the drivers know it.

Those are the nodes that get public_transport=platform, without an actual
platform being present.

Now if there is a physical platform, we draw a way or an area and tag it
highway=platform or railway=platform. Those can also get a
public_transport=platform tag. But it doesn't really matter, highway=platform
or railway=platform has all the information we need for those. In case it's
heightened, we can add wheelchair yes, if there is tactile paving, we can
add tactile_paving=yes, although I think it would be even better if we
could add explicit ways and nodes for those, as we map in more and more
detail.

What I am trying to accomplish is that bus and tram stops would be
represented by a single node, next to the highway. That those nodes get all
the tags describing the bus or tram stop and that only those nodes get
added to the route relations.

Some people say, but you should be able to 'upgrade' from a node to a way
or an area. I say: let's go for stability in the data and keep it all
contained in that single node per bus/tram stop. It's easy to work with for
both data consumers and mappers.

What this does imply is that stop_area relations should bundle the smallest
group of objects that belong together (for one side of the street at a time
or for one platform in a bus station). At present the wiki seems to say to
throw everything in there together for a group of bus stops that happen to
have the same name. But that, we can do just as well with a spatial query
on the data.

So no, adding public_transport=platform does not mean there is a physical
platform, just like highway=bus_stop doesn't mean it's part of the highway,
unfortunately both tags are slightly off. but we shouldn't get too fixated
on the meaning of those words in English, but rather what has become the
convention in OSM for them).

Polyglot

Op vr 22 jun. 2018 om 01:27 schreef Yves :

> Why adding 'platform' where there's no physical platform?
> Yves___
> 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] public_transport=platform rendering on osm-carto

[Yves]

Why adding 'platform' where there's no physical platform?
Yves___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] public_transport=platform rendering on osm-carto

[Martin Koppenhoefer]

sent from a phone

> On 22. Jun 2018, at 00:23,  
>  wrote:
> 
> And the ones that used to have only a highway=bus_stop node only require a 
> public_transport=platform node instead now. No increase in complexity.


you must add bus=yes or it would not be a bus stop. It isn’t more complex, just 
more complicated and time consuming.

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

Re: [Tagging] public_transport=platform rendering on osm-carto

[Martin Koppenhoefer]

sent from a phone

> On 21. Jun 2018, at 23:30, Jo  wrote:
> 
> If Paul feels it would be better to have those stop_postion nodes in the 
> route relations anyway, he can add them back in. They dont add information 
> though.



I am with Jo here: the stop_positions at bus stops do not add any information, 
at most they would add convenience for data consumers (if every bus stop had 
them), but OSM traditionally values mapper convenience higher than simplicity 
of data evaluation.


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

Re: [Tagging] public_transport=platform rendering on osm-carto

[osm.tagging]

> -Original Message-
> From: Martin Koppenhoefer 
> Sent: Friday, 22 June 2018 08:03
> 
> a bus stop usually didn’t have a highway=platform, just
> highway=bus_stop, only for platforms on stations the former is
> suggested.
> It is only a fraction (94k) of all bus stops (2M) that could be
> seen as simpler after a change.

And the ones that used to have only a highway=bus_stop node only require a 
public_transport=platform node instead now. No increase in complexity. So some 
are the same, and some are simpler, none are required to be more complex. So 
overall, it's simpler.



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

Re: [Tagging] public_transport=platform rendering on osm-carto

[Martin Koppenhoefer]

sent from a phone

> On 20. Jun 2018, at 19:53,  
>  wrote:
> 
> One, which is connected to the foot network. That is your 
> public_transport=platform. In this regard, PTv2 is easier than the old 
> scheme, as you no longer have two separate highway=platform and 
> highway=bus_stop. You only have a single public_transport=platform. If it’s 
> on a node, then it’s just a simple pole or otherwise marked stop without any 
> real platform, if it’s tagged on a way (representing the platform edge) or an 
> area (representing the whole platform) then you got an actual platform.


a bus stop usually didn’t have a highway=platform, just highway=bus_stop, only 
for platforms on stations the former is suggested.
It is only a fraction (94k) of all bus stops (2M) that could be seen as simpler 
after a change.

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

Re: [Tagging] public_transport=platform rendering on osm-carto

[Jo]

You guys are hilarious. I actually helped Paull Allen with his questions on
how to map that bus line. It's where the discussion about reverse role came
from, by the way.

Anyway, I removed the stop_position nodes from the route relations yes. It
shows that it's perfectly possible to map bus lines with nodes next to the
highways and without having to duplicate information across 2 objects and
then having to add both those objects to the route relations.

In general the data was improved and Paul learned how he can map a complex
bus line that does illogical things.

If Paull feels it would be better to have those stop_postion nodes in the
route relations anyway, he can add them back in. They dont add information
though.

Paul's concern was rather that the stops come first in the relation
foloowed by the ways. He would prefer to add the stops sprinkled between
the ways.

I'm looking into how feasible that would be in JOSM. There is something to
say for doig it that way, but only if there is support from the editor
software. Because the reason why we have a long string of ways, is because
now we get visual feedback that this sequence of ways is continuous. (or
not)

Anyway, I think we need to rethink how public transport should be mapped in
OSM, as what we are doing right now is too compilcated and data needs to be
duplicated between stop_position nodes and platform nodes/ways. I have been
silent about this for years, from now on I will keep hammering on this.

And to get back on topic changing the rendering of highway=platform or
railway=platform on ways is not useful. Those are just fine the way they
are. It's the platform nodes (previously highway=bus_stop) that we are
concerned about.

Jo (Polyglot)

Op do 21 jun. 2018 om 17:47 schreef :

> As I previously said, I would consider this vandalism.
>
> > -Original Message-
> > From: marc marc 
> > Sent: Friday, 22 June 2018 01:23
> > To: tagging@openstreetmap.org
> > Subject: Re: [Tagging] public_transport=platform rendering on osm-
> > carto
> >
> > Le 21. 06. 18 à 16:27, Paul Allen a écrit :
> > > Platforms are mapped but stop positions aren't (somebody who
> > thinks
> > > they shouldn't be there cleaned up after me).
> > > https://www.openstreetmap.org/relation/7620346
> >
> > if want to known who destroy stop_position in the relation, look at
> > version #18 changet 59355804 23 days ago.
> > PS: Polyglot=Jo
> >
> > The destruction of perfectly valid tags is really a problematic
> > behavior despite all the sympathy I have for Jo in many other
> > threads.
> > Fixing some stuff in a relationship does not need to destroy valid
> > info that another mapper had added previously.
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] emergency=lifeguard

[Tod Fitch]

Graeme Fitzpatrick graemefitz1 at gmail.com  

Wed Jun 20 02:13:47 UTC 2018

> So the photos on
> https://wiki.openstreetmap.org/wiki/Tag%3Aemergency%3Dlifeguard_tower 
>  &
> https://wiki.openstreetmap.org/wiki/Tag%3Aemergency%3Dlifeguard_platform 
> 
> would be your sort of mobile towers?
Sorry, I must have deleted the email from this thread from my reader so am 
replying to the archived version. I am guessing this email will start a new 
thread.

I have uploaded some photos that show the types of lifeguard facilities near me.

First is the headquarters building [1]. I don’t see any particular reason to 
include it in any emergency tagging scheme. While it is locally called the 
“clock tower” and is sometimes used used as an identifiable point for meeting 
people, near as I can tell emergency response does not directly come from there.

Second is the year round staffed tower located just off the beach on the pier. 
[2] This is a permanent structure currently tagged with building=yes and 
emergency=lifeguard_tower.

Third is one of the stations on the city beach [3]. This one happens to remain 
in place all year as it is the marker for how close swimming is allowed to the 
pier. But you can see by the design that the whole structure can be moved and 
some of other stations/towers on the beach are moved to safer locations to 
survive winter storms. This particular station/tower is not on OSM at present 
largely because I was unsure about how to tag it.

Forth is one of the near by state parks beach [4]. Similar concept to the city 
version but different construction materials, etc. Some of these are also moved 
to safer locations during the winter.

Again, the towers that are moved to safer locations during winter are all 
replaced in the same place each summer. At least close enough to the same place 
that it probably doesn’t make much difference for OSM. I can see a desire to 
distinguish between a movable lifeguard tower and one that is very definitely 
not designed to move but don’t have any good ideas on how that might be tagged.

Cheers!

[1] 
https://wiki.openstreetmap.org/wiki/File:San_Clemente_lifeguard_headquarters.jpg
[2] https://wiki.openstreetmap.org/wiki/File:San_Clemente_Lifeguard_Tower_2.jpg
[3] https://wiki.openstreetmap.org/wiki/File:San_Clemente_Lifeguard_Tower_1.jpg
[4] 
https://wiki.openstreetmap.org/wiki/File:California_State_Parks_lifeguard_tower.jpg___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Telecom local netwoks

[François Lacombe]

Hi

As to provide a little update on this topic, little improvents have been
done on the proposal document
https://wiki.openstreetmap.org/wiki/Proposed_features/Telecom_local_loop

telecom=central_office moves to telecom=exchange without change in its
definition

telecom=outdoor_dslam moves to telecom=service_device
Previous value was found confusing and not clear.
Goal is to map any standalone service equipments located in a cabinet.
Outdoor isn't mandatory, the cabinet can be installed underground, indoor
or wherever outside of an actual exchange building lacking of free space.
telecom=service_device will allows us to do indoor exchange mapping also if
we ever get able to do so someday.

I hope all 3 values telecom=exchange, telecom=service_device and
telecom=connection_point all match both telecom specialists and mappers
views and needs here

All the best

François

2018-06-13 1:12 GMT+02:00 Warin <61sundow...@gmail.com>:

> On 13/06/18 07:51, Graeme Fitzpatrick wrote:
>
>
>
>
> On 13 June 2018 at 06:54, François Lacombe 
> wrote:
>
>> Hi Warin,
>>
>> 2018-06-12 11:52 GMT+02:00 Warin <61sundow...@gmail.com>:
>>
>>>
>>> What about calling them an 'exchange' ... though it could be confused
>>> with money - foreign currency trading etc.
>>>  So umm 'communication exchange' ?
>>>
>>
>> Exchange is a good input, thank you
>>
>> telecom=exchange can't really be confused with amenity=bureau_de_change
>> can you ?
>> This would be shorter to type than telecom=telecommunication_exchange or
>> even telecom=telephone_exchange and less redundant with key name "telecom"
>> We can think about telecom=exchange_point to meet consistency with
>> telecom=connection_point
>>
>> I would really enjoy a consensus on this
>>
>
> Yep, telecom=exchange works for me :-)
>
>
> Works for me too... but don't be too hasty adopting one of 'my' ideas.
> Lets let others (and me) contemplate it for a while?
>
> ___
> 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] public_transport=platform rendering on osm-carto

[osm.tagging]

As I previously said, I would consider this vandalism.

> -Original Message-
> From: marc marc 
> Sent: Friday, 22 June 2018 01:23
> To: tagging@openstreetmap.org
> Subject: Re: [Tagging] public_transport=platform rendering on osm-
> carto
> 
> Le 21. 06. 18 à 16:27, Paul Allen a écrit :
> > Platforms are mapped but stop positions aren't (somebody who
> thinks
> > they shouldn't be there cleaned up after me).
> > https://www.openstreetmap.org/relation/7620346
> 
> if want to known who destroy stop_position in the relation, look at
> version #18 changet 59355804 23 days ago.
> PS: Polyglot=Jo
> 
> The destruction of perfectly valid tags is really a problematic
> behavior despite all the sympathy I have for Jo in many other
> threads.
> Fixing some stuff in a relationship does not need to destroy valid
> info that another mapper had added previously.
> ___
> 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] public_transport=platform rendering on osm-carto

[marc marc]

Le 21. 06. 18 à 16:27, Paul Allen a écrit :
> Platforms are mapped but stop positions aren't 
> (somebody who thinks they shouldn't be there cleaned up after me).
> https://www.openstreetmap.org/relation/7620346 

if want to known who destroy stop_position in the relation,
look at version #18 changet 59355804 23 days ago.
PS: Polyglot=Jo

The destruction of perfectly valid tags is really a problematic behavior 
despite all the sympathy I have for Jo in many other threads.
Fixing some stuff in a relationship does not need to destroy valid info 
that another mapper had added previously.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] iD presets

[Christoph Hormann]

On Thursday 21 June 2018, Bryan Housel wrote:
>
> Just going to cut my reply off here.  There was some vague stuff in
> your message about “poisoning OSM” that didn’t seem to be a serious
> question.

That wasn't a question, that was my attempt to explain a fundamental 
difference in views between us.  And the runway was an example meant to 
illustrate this difference.  It is unfortunate that i was not able to 
make my viewpoint on this clear to you because i think understanding 
different perspectives on this matter (the roles of different people 
and different interests in tagging development) would help you in 
making decisions regarding tagging presets.

Anyway - i look forward to iD offering the possibility to include 
different presets and hope this will lead to more diversity and more 
choices in tagging presets available to mappers.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] public_transport=platform rendering on osm-carto

[Paul Allen]

On Wed, Jun 20, 2018 at 10:24 PM, Jo  wrote:

>
> It's probably best to provide a link to the actual route relation. It's
> indeed a complex one.
>

For those who care, it's https://www.openstreetmap.org/relation/7620346 (I
think I now have everything in the
correct order in the relation).  I find it hard to figure out what's going
on from looking at the relation and I ride this
bus!  Good luck to any data consumer using the query tool trying to figure
it out.

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

Re: [Tagging] iD presets

[Bryan Housel]

> On Jun 21, 2018, at 6:16 AM, Christoph Hormann  wrote:
> 
> Then why do you object to Frederik's idea of separating the tagging 
> presets from editor development and give up control over the decisions? 

I offered to do exactly this a few years ago:
https://github.com/osmlab/editor-presets/pull/2 

Nobody cared, so it sat and eventually went stale over a few months.

I wouldn’t do it today.  

Looking back on the iD changelogs 
 (and scanning 
through the still open issues) there are lots of usability items that affect 
the preset system.
Some recent examples of things I couldn’t do (quickly) if the presets were an 
external project:

* We changed all the icons to support multiple iconsets 
  and this meant that I needed 
to change all the icon names in all the presets.
* We implemented a check to support min and max field values 
, and it meant that I needed 
to go through all the presets and add some properties to certain ones.
* We renamed the field label from “Phone” to “Telephone” 
 so that a user can type 
either value in the Add field dropdown.

Usability and speed of development are very important to me, and these are 
things that would suffer if I split the presets off into a separate project.


> I am glad you work on improving possibilities for choice of presets and 
> this could over time be used to allow alternatives - like converting 
> the JOSM presets (which already includes a lot of specialized add on 
> preset collections) or managing diverse independent preset collections.  
> This is IMO the best way to go ahead here.

Yes allowing people to override the presets at runtime is something I want to 
add.  (I almost built it at the hackathon.)

For the curious, the somewhat tricky part about this is the bootstrap process.  
Currently, presets in iD are ready at startup and translations are loaded in 
later.  If a user specifies a replacement preset file, we need to delay some 
code until the browser has fetched everything.


Just going to cut my reply off here.  There was some vague stuff in your 
message about “poisoning OSM” that didn’t seem to be a serious question.  Also 
for the record, I’m fine with either method of mapping runways (I prefer to map 
them as a 2 node way myself).  iD supports both methods (drawn as a linear way 
or as a closed way area).  

If you don’t use iD, I encourage you to try it out..
Please report any specific bugs for feature requests on our issue tracker:  
https://github.com/openstreetmap/iD   


Thanks, Bryan

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

Re: [Tagging] A new Tag for "helicopter services"?

[gorgonz]

Am 20.06.2018 um 00:51 schrieb Graeme Fitzpatrick:
> On 20 June 2018 at 03:43, gorgonz  > wrote:
>
> imho  such a place is like a clerical. Someone sits in the "office"
> managing and acquiring orders ;-). In so far, I think that office
> is ok.
> Or did I misunderstand something? English is not my mother tongue.
>
>
> No, you're doing very well! :-)
>
> Yes, I'd agree with you that it's an office, because that's where all
> the paperwork & admin is done.
>
> So if we all agree on office=air_charter, would you then carry it down
> to types of charter eg joy flights, training, aerial photo's etc or
> just leave that to the company's website to explain?
Thanks graeme for Your comment :-)

Reading cliffords suggestion to subclassify it with devices, I liked the
idea! But if we subclassify it, then it might be a good idea to reflect
first of all, which kind of information are people looking for.

In this discussion we learned two different types:

- devices like drones, helicopter, and fixed wing decices
- services like joy flights, training, aerial photo's etc

Most of the companies tend to fully utilize their capacities and as a
result will offer many of the services in parallel. This would lead us
to an enumeration instead of a fixed value.. (How) could this be
handled? Semicolon separated? Is it a good road?

I would suggest that people will likely look for a service in first
place while the exact device.ain't that important.

I'm not sure, if subclassification makes sense. So, I ask all of You:
what You are thinking about this?


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

Re: [Tagging] Official OSMF editor (was: emergency=lifeguard)

[Frederik Ramm]

Martin:
> The operation of the OSMF editor should not be in conflict with the
> OSMF mission. 

Bryan:
> iD is not an “OSMF editor”.  I literally have nothing to do with OSMF.

Bryan is right; iD is an independent project and not controlled by the OSMF.

iD is, of course, afforded considerable status by the OSMF putting it up
as their main in-browser editor. The OSMF could choose to afford this
status to another editor, or to a forked and community-curated version
of iD that replaces Bryan's tag design decisions by something else, but
I don't currently see anything present itself.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [Tagging] iD presets

[Christoph Hormann]

On Thursday 21 June 2018, Bryan Housel wrote:
>
> As I see it, the users of iD and the community are deciding which
> presets get included.  I might recommend a change in what the display
> name should be, or what icon it should have, but I almost never tell
> someone that they can’t add a preset or field (some examples coming
> up next).

Then why do you object to Frederik's idea of separating the tagging 
presets from editor development and give up control over the decisions? 
No specifc suggestion has been made so far how such a project would be 
managed (and as i have already said i have concerns about one single 
preset collection with no alternatives under any kind of central 
control) but still this remains an important question here for me.

I am glad you work on improving possibilities for choice of presets and 
this could over time be used to allow alternatives - like converting 
the JOSM presets (which already includes a lot of specialized add on 
preset collections) or managing diverse independent preset collections.  
This is IMO the best way to go ahead here.

> I actually think being more involved in tagging discussions here is
> probably the solution to educating mappers about how to design tags
> in a way that is easier for software (and users) to work with.

I think this comment (as well as your list of criteria for preset 
decisions) greatly illustrates where we differ on a very fundamental 
level.  IMO the whole point of OSM is having a mapper centric approach 
to tagging, mappers decide which tags to use based on what is most 
convenient for them.  I am all for educating mappers how to better 
achieve this because many new mappers struggle with that obviously.  
But the aim should not be to cater developers of software (or 
indicrectly the users of the software as you put it).  Pursuing this 
aim on a large scale would be poison for OSM.

To give you a specific example - not something with particularly high 
impact but still one of my favorite in this regard.  Mapping an 
aeroway=runway with a two note way and a width tag is quite clearly the 
quickest, most compact, most convenient and at the same time perfectly 
precise method to map it.  But for editor developers like you this is 
complicated because you have to visualize the runway width and support 
interactive manipulation of it.  For you it is way more convenient if 
mappers agree to map runways with polygons.  Ok, this particular case 
is not strictly a pure tagging problem but i hope it illustrates the 
difference between a mapper centric approach to tagging and a developer 
or data user centric approach and why i think it is highly important to 
stick to the former.

-- 
Christoph Hormann
http://www.imagico.de/

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