Re: [Tagging] Follow-Up Proposal - voting ended - (Tramtrack on highway)

2018-12-03 Thread Jo
I look forward to a new vote and will vote in favour of what you're
proposing now.

Polyglot

On Mon, Dec 3, 2018 at 8:29 PM Nikulainen, Jukka K <
jukka.nikulai...@helsinki.fi> wrote:

> Hello Paul, and thank you for your input!
>
> You are indeed correct that my follow-up proposal would very radically cut
> corners and be, to say the least, unorthodox. I'm certainly sorry if it
> offended the sensibilities of anyone.
>
> I can see now that it could be construed as malicious and you are
> certainly right that implementing a new vote on a new proposal would not be
> an excessive amount of work.
>
> Indeed, doing a new proposal and a new vote seems the right thing to do,
> and I'll get to it soon!
>
> Please let me explain the rationale my odd follow-up proposal, as a few
> lines in your response did catch my eye:
>
> > 1) Your analysis is correct. The new proposal would meet with universal
> acclaim and pass unanimously.
>
> I don't quite understand how you could possibly have reached the
> conclusion that I would expect "universal acclaim" or unanimity, from
> anything that I've written in the follow-up. It seems to me painstakingly
> obvious that neither would ensue, judging only from the opposing votes and
> critical comments on the original proposal.
>
> Furthermore, responding to your second point, I was not aware that
> "universal acclaim" was required for a proposal to pass as you suggest. At
> least the proposal process wiki page seems to say otherwise. But of course
> I could just be moronically illiterate, in which case: mea maxima culpa!
>
> I would also argue that my follow-up proposal isn't based on blitheness.
> Rather it is based on the sixteen approving votes on the original proposal
> and the quite acute and perceptive critical comments they contained and
> conveyed. Nor is expediency alone my motivation (though I must admit, it is
> a consideration too).
>
> I, rather, worry whether enough people will be interested to vote again on
> a similar proposal only with changed tag-values. Many of the interesting
> critical comments and interested people in fact came forth only after
> voting had started and the proposal could no longer be changed. It would be
> a shame if the idea (which, again, _did_ garner support on the first round)
> would be lost in the absence of interest on a second proposal and vote. But
> maybe I just worry too much.
>
> Sincerely,
> Jukka Nikulainen (Tolstoi21)
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - Voting - (Tramtrack_on_highway)

2018-11-21 Thread Jo
It is still possible to tag a highway with 1 single railway track on it
highway=* + railway=tram/train. But this proposal is for the case where the
highway has 2 railiway tracks which are already mapped separately because
the way railways curve is different from how how highways behave at
intersections.

This tag is only a hint for routers, so cyclists can try to avoid such
ways. What it really means is, there are railway tracks, BUT they are
already mapped on  separate OSM object that runs mostly parallel to this
highway.

Polyglot

El jue., 22 nov. 2018 a las 6:55, Yves () escribió:

> Sergio,
> This is not an issue, anyway some will argue that the highway is a highway
> AND a railway too, so they would be happy too.
> 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] Feature Proposal - Voting - (Tramtrack_on_highway)

2018-11-21 Thread Jo
The whole issue is that due to tram rails bending differently than road
ways, the tram rails are mapped on their own OSM ways. This gives a nicely
detailed rendering, a better description of reality, but now the
information that for the straight parts the rails are embedded into the
highway is missing. It's just a model, not a highly detailed architectural
plan.

I would also be in favour of not using railway=*,

embedded_rails conveys more information without going into conflict with
the railway ways. We don't want to render them 3 times if there are 2
tracks.

Polyglot

El mié., 21 nov. 2018 a las 10:04, Nikulainen, Jukka K (<
jukka.nikulai...@helsinki.fi>) escribió:

> Sorry, I forgot to comment on this earlier
>
> >embedded_rails=yes or even more precise
> >embedded_rails=tram | embedded_rails=railway.
> >The latter is even worse for bicycles, because the rail grooves are
> >broader.
>
> It is true that that would be more precise, but are there in fact any
> examples of this? I mean a railway that runs parallel to _and_ on a road?
> Usually highways do cross railways, but this is not a problem, since one
> approaches the rails (and the grooves) tangentially and they do not pose a
> great danger.
>
> But you are of course correct that this tag would allow for more specific
> tagging, if this is something that is needed.
>
> Sincerely,
> Jukka (Tolstoi21)
>
> ___
> 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 Timetables

2018-11-08 Thread Jo
One thing that I found while trying this 'little' exercise is that it would
be good to have an object that 'represents' an operator or a network. I was
using this to keep track of holidays with Sunday schedule and when school
vacations are, because that influences the timetables, but it  could
definitely also serve to point to where one can find a GTFS for the
operator/network/agency and how GTFS fields translate to OSM tags:

In my region I have started to use ref:De_Lijn=102345, in the GTFS feed I
found this corresponds to the stop_code field.

What I plan to do is to add a url tag to all the stops, that lead to a web
page with realtime for each separate stop. On the route_master relations, I
plan to point to the operator's web site's page describing that particular
line.

Polyglot

Op do 8 nov. 2018 om 22:53 schreef Paul Allen :

>
> On Thu, Nov 8, 2018 at 9:27 PM Andy Townsend  wrote:
>
>>
>> FWIW I've just used https://www.traveline.info/ to find journey between
>> Porthmadog and Criccieth and Bearsden and Milton of Campsie (yes!  There
>> are ones at this time of night!) so the main site does  indeed work in
>> Wales and Scotland.
>>
>
> Yes, it works.  But it doesn't have an option to use Cymraeg.  Which would
> be a show-stopper
> for some people in Wales, who would rather use a site that is completely
> broken if it is in
> Welsh rather than a site that works but is only available in English.
>
> Also, the .cymru site has something the .info site does not, route maps.
> I just pulled up a local
> route and looked at its map.  Admittedly it is a very weird and
> complicated route (reminiscent of
> a spider web on drugs), but this route map gets it wrong in many, many
> ways:
>
> https://www.traveline.cymru/timetables/?routeNum=408_id=0_key=408MFRBA1
>
> Kinda reminds me of a Google bus route I looked at several years ago which
> apparently drew straight
> lines (through houses and across fields) between timetabled stops rather
> than following a road between
> them.  Told me to get to a location on the actual bus route by getting off
> a mile beyond and walking
> back because it had joined the stops with straight lines through fields.
> It was only by playing around
> that I got it to show the route it was using, which at one point ploughed
> through the middle of a small
> housing estate and took a straight line across farmland to the next
> timetabled stop.
>
>
>> Other than Traveline, plenty of other OSMers* have worked in the
>> transport / route planning area - both "startups" and more traditional
>> transport authorities.  I know of others have looked at consuming GTFS for
>> bus routes in England, and found that it can be a bit complicated as the
>> same numbered route can exist multiple times in the GTFS feed with only
>> minor differences for the variations - it's not just a simple case of "grab
>> all that data from there and use it" unless you're prepared to do quite a
>> bit of processing.  You really need to be an app to do anything useful with
>> the data (such as https://oeffi.schildbach.de/index.html - which works
>> everywhere in GB that I've tried it and presumably uses Traveline's feeds,
>> or something similar) - anything else would just be "reinventing GTFS".
>>
>
> So what's the copyright situation with Traveline's GTFS feeds?  Are we
> free to use any of them to add
> routes to OSM?  Obviously, they'd have to be sanity-checked...
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Public Transport Timetables

2018-11-07 Thread Jo
(started writing this several hours ago)

The way this proposal is evolving, there will be 2  versions. One that
gives an approximate idea of how much time there is between 2 buses for a
given time of day/day of week. Those can be added as tags on the route
relations.

That one should not be dismissed outright.

And another that goes into full detail, listing all the departures at the
first stop and then lists all stops, with the most common times between
stops as roles. For this we would need separate public_transport=timetable
relations.

I've been trying how that could work and I can confirm what everybody
already knew: it's a lot of work, even for lines that seem relatively
simple at first sight! :-) An incredible time sink.

It is an interesting exercise though and I found some errors in the route
relations while doing it.

One of the shortcuts I took when creating route relations is that I only
mapped the longest variations. An advantage of adding the timetables the
way I'm proposing it, is that the stop sequences of the shorter variations
now also become visible. This may make validation easier to do. When stops
are not in order anymore in a route relation, the validator can detect that.

But it's a lot of data to add and it becomes stale very quickly, plus it's
hard to verify whether it's still OK, or not, even more so than the route
relations for the buses. The only advantage is that they don't
'deteriorate' due to other people mapping. Errors are introduced in route
relations all the time because they are so 'fragile', due to ways getting
split, removed/readded to OSM, but not to the relations, etc.

Anyway, I wanted to make sure that the proposal is as good as can be, but
I'm not convinced that it's maintainable for a larger region either.
Of course, 10 years ago, I was not convinced any small group of volunteers
would be able to create a detailed map of the world.

I think, at present, it's far more important we get to a way of mapping
public transport with a single object (preferably a node next to the
highway) to represent each stop.

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


Re: [Tagging] Public Transport Timetables

2018-11-06 Thread Jo
Indeed, a mapper who wants to add this and who can't find the information
on the internet or in a booklet, would have travel to the first stop, take
note of all the departure times and then establish the deltas between all
the stops of the itinerary.
If that's the case, such a mapper would probably better use the tags based
method on the route relations.

It all depends on how much detail you want to add (and maintain in the long
run).

Another weakness of the relation pet stop/route pair method is that it will
be very hard to encode the exceptions; not on Wednesdays, only on Fridays,
etc.

Jo

Op di 6 nov. 2018 om 20:22 schreef djakk djakk :

> Ok I see.
>
> I am still a bit reluctant to your proposal since the travelling time
> between 2 stops can vary during the day, especially for train routes.
> Ok there is the possibility of adding a new timetable relation ...
>
> Moreover, I think that data inputs from the ground can not be done with
> your proposal (it needs to know the timetable for the whole line), we’ll
> depend on GTFS file actually :-/
>
> Julien “djakk”
>
>
>
> Le mar. 6 nov. 2018 à 19:27, Jo  a écrit :
>
>> Yes, very hard to debug and we already established some change every few
>> months. So after a change from the operator. One traveler will update one
>> of those schedules, Another may do so for 3 stops down the line, in the
>> mean time the stops in between and after are not updated yet. A maintenance
>> nightmare. The way I proposed it, suffers less from that problem. When
>> timetables change it's usually that trips are added or removed or their
>> start time changes slightly. The time to get from one stop to the next will
>> remain constant, most of the time.
>>
>> Jo
>>
>> Op di 6 nov. 2018 om 18:40 schreef djakk djakk :
>>
>>> I don’t get it ...
>>>
>>> With my point of view, one route with 15 stops has 15 timetables, each
>>> timetable describes the arrival time and the departure time of several
>>> trips at the stop.
>>>
>>> There must be the same number of trips along the stops’ timetables.
>>> (Otherwise this is an other route).
>>>
>>> You mean, if somebody messed up and add an extra trip inside a
>>> timetable, this would be hard to figure ?
>>>
>>> Julien “djakk”
>>>
>>>
>>> Le mar. 6 nov. 2018 à 18:30, Jo  a écrit :
>>>
>>>> If you have a single one for a stop/route pair, no problem. As soon as
>>>> you have a few hundred and the information in them starts to conflict with
>>>> other another timetable relation for the same route it will be extremely
>>>> hard to figure out where it went wrong.
>>>>
>>>> Polyglot
>>>>
>>>> Op di 6 nov. 2018 om 17:08 schreef djakk djakk :
>>>>
>>>>> In which case a timetable per stop and per route is unmaintable ?
>>>>>
>>>>> Julien “djakk”
>>>>>
>>>>>
>>>>> Le mar. 6 nov. 2018 à 16:59, djakk djakk  a
>>>>> écrit :
>>>>>
>>>>>> I think it is important to have an osm object describing the
>>>>>> timetable user-oriented for simple editing without any tool.
>>>>>> The mapper is at a bus stop, takes a picture of the timetable, can
>>>>>> import it later in osm without the need of any extra tool.
>>>>>> Validator can be inside a tool.
>>>>>>
>>>>>> Julien « djakk »
>>>>>>
>>>>>>
>>>>>> Le mar. 6 nov. 2018 à 16:46, djakk djakk  a
>>>>>> écrit :
>>>>>>
>>>>>>> Almost that ! Sometimes bus stops does not have their official
>>>>>>> timetable, the user have to refer to the closest previous bus stop 
>>>>>>> having
>>>>>>> an official timetable. So this kind of bus stop may not have a 
>>>>>>> timetable in
>>>>>>> osm (except an osm mapper really wants to put it into osm, knowing per
>>>>>>> habits the schedule).
>>>>>>>
>>>>>>>
>>>>>>> Julien « djakk »
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Le mar. 6 nov. 2018 à 16:28, Jo  a écrit :
>>>>>>>
>>>>>>>> You mean per stop/route pair? That's an incredible s amount of
>>>>>>>> relations! It seems to me that it would be a nighmare to try and 
>>

Re: [Tagging] Public Transport Timetables

2018-11-06 Thread Jo
Yes, very hard to debug and we already established some change every few
months. So after a change from the operator. One traveler will update one
of those schedules, Another may do so for 3 stops down the line, in the
mean time the stops in between and after are not updated yet. A maintenance
nightmare. The way I proposed it, suffers less from that problem. When
timetables change it's usually that trips are added or removed or their
start time changes slightly. The time to get from one stop to the next will
remain constant, most of the time.

Jo

Op di 6 nov. 2018 om 18:40 schreef djakk djakk :

> I don’t get it ...
>
> With my point of view, one route with 15 stops has 15 timetables, each
> timetable describes the arrival time and the departure time of several
> trips at the stop.
>
> There must be the same number of trips along the stops’ timetables.
> (Otherwise this is an other route).
>
> You mean, if somebody messed up and add an extra trip inside a timetable,
> this would be hard to figure ?
>
> Julien “djakk”
>
>
> Le mar. 6 nov. 2018 à 18:30, Jo  a écrit :
>
>> If you have a single one for a stop/route pair, no problem. As soon as
>> you have a few hundred and the information in them starts to conflict with
>> other another timetable relation for the same route it will be extremely
>> hard to figure out where it went wrong.
>>
>> Polyglot
>>
>> Op di 6 nov. 2018 om 17:08 schreef djakk djakk :
>>
>>> In which case a timetable per stop and per route is unmaintable ?
>>>
>>> Julien “djakk”
>>>
>>>
>>> Le mar. 6 nov. 2018 à 16:59, djakk djakk  a
>>> écrit :
>>>
>>>> I think it is important to have an osm object describing the timetable
>>>> user-oriented for simple editing without any tool.
>>>> The mapper is at a bus stop, takes a picture of the timetable, can
>>>> import it later in osm without the need of any extra tool.
>>>> Validator can be inside a tool.
>>>>
>>>> Julien « djakk »
>>>>
>>>>
>>>> Le mar. 6 nov. 2018 à 16:46, djakk djakk  a
>>>> écrit :
>>>>
>>>>> Almost that ! Sometimes bus stops does not have their official
>>>>> timetable, the user have to refer to the closest previous bus stop having
>>>>> an official timetable. So this kind of bus stop may not have a timetable 
>>>>> in
>>>>> osm (except an osm mapper really wants to put it into osm, knowing per
>>>>> habits the schedule).
>>>>>
>>>>>
>>>>> Julien « djakk »
>>>>>
>>>>>
>>>>>
>>>>> Le mar. 6 nov. 2018 à 16:28, Jo  a écrit :
>>>>>
>>>>>> You mean per stop/route pair? That's an incredible s amount of
>>>>>> relations! It seems to me that it would be a nighmare to try and maintain
>>>>>> it that way. At first sight it seems simpler, but with the new proposal i
>>>>>> came up with, you can see how the stops of a variation in itinerary tie
>>>>>> together.
>>>>>>
>>>>>> If the vehicle remains in the station longer, the roles could become
>>>>>> 00:30-00:35 instead of simply 00:35 for the departure offset to the time
>>>>>> the vehicle left at its first stop.
>>>>>>
>>>>>> Seeing the stops in the timetable relation in the order they are
>>>>>> served also enables comparing this with the stops sequence in the route
>>>>>> relation they refer to, adding additional possibilities for validation of
>>>>>> the data.
>>>>>>
>>>>>> The stops in a timetable sequence should always be a subset of the
>>>>>> stops in a route relation and appear in the same order.
>>>>>>
>>>>>> Polyglot
>>>>>>
>>>>>>
>>>>>> Op di 6 nov. 2018 om 16:07 schreef djakk djakk >>>>> >:
>>>>>>
>>>>>>> I’ll agree with Leif, having a timetable relation per stop is
>>>>>>> better.
>>>>>>>
>>>>>>>
>>>>>>> Yes Leif, there can be a delay expressed in minutes instead of an
>>>>>>> arrival-departure pair of time.
>>>>>>>
>>>>>>> Julien « djakk »
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> L

Re: [Tagging] Public Transport Timetables

2018-11-06 Thread Jo
If you have a single one for a stop/route pair, no problem. As soon as you
have a few hundred and the information in them starts to conflict with
other another timetable relation for the same route it will be extremely
hard to figure out where it went wrong.

Polyglot

Op di 6 nov. 2018 om 17:08 schreef djakk djakk :

> In which case a timetable per stop and per route is unmaintable ?
>
> Julien “djakk”
>
>
> Le mar. 6 nov. 2018 à 16:59, djakk djakk  a écrit :
>
>> I think it is important to have an osm object describing the timetable
>> user-oriented for simple editing without any tool.
>> The mapper is at a bus stop, takes a picture of the timetable, can import
>> it later in osm without the need of any extra tool.
>> Validator can be inside a tool.
>>
>> Julien « djakk »
>>
>>
>> Le mar. 6 nov. 2018 à 16:46, djakk djakk  a
>> écrit :
>>
>>> Almost that ! Sometimes bus stops does not have their official
>>> timetable, the user have to refer to the closest previous bus stop having
>>> an official timetable. So this kind of bus stop may not have a timetable in
>>> osm (except an osm mapper really wants to put it into osm, knowing per
>>> habits the schedule).
>>>
>>>
>>> Julien « djakk »
>>>
>>>
>>>
>>> Le mar. 6 nov. 2018 à 16:28, Jo  a écrit :
>>>
>>>> You mean per stop/route pair? That's an incredible s amount of
>>>> relations! It seems to me that it would be a nighmare to try and maintain
>>>> it that way. At first sight it seems simpler, but with the new proposal i
>>>> came up with, you can see how the stops of a variation in itinerary tie
>>>> together.
>>>>
>>>> If the vehicle remains in the station longer, the roles could become
>>>> 00:30-00:35 instead of simply 00:35 for the departure offset to the time
>>>> the vehicle left at its first stop.
>>>>
>>>> Seeing the stops in the timetable relation in the order they are served
>>>> also enables comparing this with the stops sequence in the route relation
>>>> they refer to, adding additional possibilities for validation of the data.
>>>>
>>>> The stops in a timetable sequence should always be a subset of the
>>>> stops in a route relation and appear in the same order.
>>>>
>>>> Polyglot
>>>>
>>>>
>>>> Op di 6 nov. 2018 om 16:07 schreef djakk djakk :
>>>>
>>>>> I’ll agree with Leif, having a timetable relation per stop is better.
>>>>>
>>>>>
>>>>> Yes Leif, there can be a delay expressed in minutes instead of an
>>>>> arrival-departure pair of time.
>>>>>
>>>>> Julien « djakk »
>>>>>
>>>>>
>>>>>
>>>>> Le mar. 6 nov. 2018 à 16:04, djakk djakk  a
>>>>> écrit :
>>>>>
>>>>>> In order to reduce the length of the value of the departures= tag,
>>>>>> should we allow this kind of abstraction level : departures=5:35 ; 6:35 ;
>>>>>> [7-19]:[05;35] ; 20:35 ; 21:35  ?
>>>>>>
>>>>>> Julien « djakk »
>>>>>>
>>>>>>
>>>>>> Le mar. 6 nov. 2018 à 15:41, djakk djakk  a
>>>>>> écrit :
>>>>>>
>>>>>>> Martin, maybe locals do know their bus stop timetable, as they
>>>>>>> always use the service they may memorize the schedules ... ?
>>>>>>>
>>>>>>> Julien
>>>>>>>
>>>>>>>
>>>>>>> Le lun. 5 nov. 2018 à 17:08, Jo  a écrit :
>>>>>>>
>>>>>>>> Hi Leif,
>>>>>>>>
>>>>>>>> You made me do it! :-) I sort of stole your proposal and started
>>>>>>>> creating a new one. It differs in rather important ways from your 
>>>>>>>> proposal,
>>>>>>>> so I preferred not modifying your wiki page. I also think it's 
>>>>>>>> important to
>>>>>>>> decouple the (voting for a) full timetable solution from the solution 
>>>>>>>> where
>>>>>>>> tags are added to indicate interval during 'opening_hours' or a route,
>>>>>>>> which is a lot more likely to be accepted.
>>>>>>>>
>>>>>>>> So

Re: [Tagging] Public Transport Timetables

2018-11-06 Thread Jo
You mean per stop/route pair? That's an incredible s amount of relations!
It seems to me that it would be a nighmare to try and maintain it that way.
At first sight it seems simpler, but with the new proposal i came up with,
you can see how the stops of a variation in itinerary tie together.

If the vehicle remains in the station longer, the roles could become
00:30-00:35 instead of simply 00:35 for the departure offset to the time
the vehicle left at its first stop.

Seeing the stops in the timetable relation in the order they are served
also enables comparing this with the stops sequence in the route relation
they refer to, adding additional possibilities for validation of the data.

The stops in a timetable sequence should always be a subset of the stops in
a route relation and appear in the same order.

Polyglot


Op di 6 nov. 2018 om 16:07 schreef djakk djakk :

> I’ll agree with Leif, having a timetable relation per stop is better.
>
>
> Yes Leif, there can be a delay expressed in minutes instead of an
> arrival-departure pair of time.
>
> Julien « djakk »
>
>
>
> Le mar. 6 nov. 2018 à 16:04, djakk djakk  a écrit :
>
>> In order to reduce the length of the value of the departures= tag, should
>> we allow this kind of abstraction level : departures=5:35 ; 6:35 ;
>> [7-19]:[05;35] ; 20:35 ; 21:35  ?
>>
>> Julien « djakk »
>>
>>
>> Le mar. 6 nov. 2018 à 15:41, djakk djakk  a
>> écrit :
>>
>>> Martin, maybe locals do know their bus stop timetable, as they always
>>> use the service they may memorize the schedules ... ?
>>>
>>> Julien
>>>
>>>
>>> Le lun. 5 nov. 2018 à 17:08, Jo  a écrit :
>>>
>>>> Hi Leif,
>>>>
>>>> You made me do it! :-) I sort of stole your proposal and started
>>>> creating a new one. It differs in rather important ways from your proposal,
>>>> so I preferred not modifying your wiki page. I also think it's important to
>>>> decouple the (voting for a) full timetable solution from the solution where
>>>> tags are added to indicate interval during 'opening_hours' or a route,
>>>> which is a lot more likely to be accepted.
>>>>
>>>> So here goes:
>>>>
>>>> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>>>>
>>>> Please let me know what you think. What I still haven't figured out yet
>>>> is how to differ weekdays that fall in school holiday periods from "normal"
>>>> weekdays. So work in progress.
>>>>
>>>> Polyglot
>>>>
>>>> Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <354...@gmail.com>:
>>>>
>>>>> Polyglot:
>>>>>
>>>> I think that having a timetable relation for each stop is less
>>>>> complicated than having one per route.  There are several advantages to
>>>>> this:
>>>>> 1) People can easily add a single relation at a time, rather than
>>>>> having to do the entire line at one time.  This could make it much easier
>>>>> to, for example, have a StreetComplete quest asking "What are the arrival
>>>>> times of bus X at this bus stop?"  iD could also have a field at bus stops
>>>>> with "arrivals for each parent bus route" that would allow people to
>>>>> seamlessly create timetable relations.  It also makes more features
>>>>> possible in the future, such as additional tags to each timetable.
>>>>> 2) The system is easier for newbies to learn to use.
>>>>>
>>>>> The disadvantage is that there are now a ton of relations per bus /
>>>>> train / subway route.  Creating these could made easier by a new JOSM
>>>>> plugin.  Also, if someone wanted to delete all timetable relations that 
>>>>> are
>>>>> part of a route, they could simply use this overpass query to download the
>>>>> data into JOSM and then delete all of the timetable relations:
>>>>> https://overpass-turbo.eu/s/Dlf
>>>>>
>>>>> If people really prefer a single timetable relation for each route,
>>>>> then I will go with that.
>>>>>
>>>>> Julien:
>>>>> Why not have a "delay"=">>>> at this platform>" tag instead of separate arrivals/departures tags?
>>>>>
>>>>> Thanks,
>>>>> Leif Rasmussen
>>>>> ___
>>>>> 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] Public Transport Timetables

2018-11-05 Thread Jo
Hi Leif,

You made me do it! :-) I sort of stole your proposal and started creating a
new one. It differs in rather important ways from your proposal, so I
preferred not modifying your wiki page. I also think it's important to
decouple the (voting for a) full timetable solution from the solution where
tags are added to indicate interval during 'opening_hours' or a route,
which is a lot more likely to be accepted.

So here goes:
https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables

Please let me know what you think. What I still haven't figured out yet is
how to differ weekdays that fall in school holiday periods from "normal"
weekdays. So work in progress.

Polyglot

Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <354...@gmail.com>:

> Polyglot:
> I think that having a timetable relation for each stop is less complicated
> than having one per route.  There are several advantages to this:
> 1) People can easily add a single relation at a time, rather than having
> to do the entire line at one time.  This could make it much easier to, for
> example, have a StreetComplete quest asking "What are the arrival times of
> bus X at this bus stop?"  iD could also have a field at bus stops with
> "arrivals for each parent bus route" that would allow people to seamlessly
> create timetable relations.  It also makes more features possible in the
> future, such as additional tags to each timetable.
> 2) The system is easier for newbies to learn to use.
>
> The disadvantage is that there are now a ton of relations per bus / train
> / subway route.  Creating these could made easier by a new JOSM plugin.
> Also, if someone wanted to delete all timetable relations that are part of
> a route, they could simply use this overpass query to download the data
> into JOSM and then delete all of the timetable relations:
> https://overpass-turbo.eu/s/Dlf
>
> If people really prefer a single timetable relation for each route, then I
> will go with that.
>
> Julien:
> Why not have a "delay"=" this platform>" tag instead of separate arrivals/departures tags?
>
> Thanks,
> Leif Rasmussen
> ___
> 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 Timetables

2018-11-03 Thread Jo
You are right, for the concrete case of De Lijn it will be better to link
to their realtime data from the stops and add a url to the route relations
for the timetables. I'm merely using these as a test case, a proof of
concept. I'm not planning to add all of them. I think it does make sense
for the school, market and student buses that run relatively infrequently.

Jo


Op za 3 nov. 2018 om 23:16 schreef OSMDoudou <
19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com>:

> Considering De Lijn may share their data as GTFS, isn’t it a better effort
> to integrate instead of duplicate existing data?
>
>
> https://www.delijn.be/en/zakelijk-aanbod/reisinfodata/gebruik-onze-data.html
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Public Transport Timetables

2018-11-03 Thread Jo
I'm mostly experimenting to figure out what can work. My initial though was
a relation per route/stop pair, but that means a lot of relations. Then I
was thinking: it would be nice to have an idea about the approximate time
to get to the next stop, which led to what I did now. Taking that idea a
bit further, why stop at only the next stop, if you can describe the whole
itinerary?

I do think we need a plugin to make handling the information easier. I
think it can easily be added to PT_Assistant if we manage to find someone
who can code in JAVA.

What I like about doing it this way, is that it becomes possible to
determine what will be the final stop for the particular bus that passes at
that stop at that time. This is something we didn't have yet.

The other thing that is nice is that we now have a basis to sort the stops
in the route relations on. (atm PT_Assistant has functionality to sort them
along the highways, if they are sorted correctly).

For someone entering the data, it's enough to enter the departures times
for the first stop. If the times between the stops are not known yet, the
roles remain empty at first. Or we could put sequence numbers in there.
About that, I do notice some have the same minute, it would be nice to have
a way to sort the stops based on the times though.

If someone entered the times at a stop somewhere in the middle of the
itinerary a tool can help adapt the times afterwards.

I'm going to try and apply this to this 'route from hell' (47 itinerary
variations!) :
https://b2cservices.delijn.be/rise-api-pdf/pdf/dienstregelingen/entiteit/4/lijnnummer/201/richting/10/lijnnummerpubliek/20a/dienstregeling_20a.pdf?gebundeldeLijnen=false=true=all=false=06-11-2018=1541278207591

That PDF only describes what itineraries it takes on weekdays outside of
school holidays...

Jo

Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <354...@gmail.com>:

> Polyglot:
> I think that having a timetable relation for each stop is less complicated
> than having one per route.  There are several advantages to this:
> 1) People can easily add a single relation at a time, rather than having
> to do the entire line at one time.  This could make it much easier to, for
> example, have a StreetComplete quest asking "What are the arrival times of
> bus X at this bus stop?"  iD could also have a field at bus stops with
> "arrivals for each parent bus route" that would allow people to seamlessly
> create timetable relations.  It also makes more features possible in the
> future, such as additional tags to each timetable.
> 2) The system is easier for newbies to learn to use.
>
> The disadvantage is that there are now a ton of relations per bus / train
> / subway route.  Creating these could made easier by a new JOSM plugin.
> Also, if someone wanted to delete all timetable relations that are part of
> a route, they could simply use this overpass query to download the data
> into JOSM and then delete all of the timetable relations:
> https://overpass-turbo.eu/s/Dlf
>
> If people really prefer a single timetable relation for each route, then I
> will go with that.
>
> Julien:
> Why not have a "delay"=" this platform>" tag instead of separate arrivals/departures tags?
>
> Thanks,
> Leif Rasmussen
> ___
> 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 Timetables Proposal RFC

2018-11-03 Thread Jo
I have been using commas between the times, maybe semicolon would be better
(not for readability though).

Op za 3 nov. 2018 om 14:01 schreef djakk djakk :

> Maybe we can put that optional piece of information inside the departures
> key : departures=7:40,7:45 ; 8:40,8:45 -> means the train or the bus
> arrives at the stop at 7:40 or 8:40 and leaves 5 minutes later.
>
> Arrival and departure time are separated by a comma, and different
> departures are separated by a semicolon.
>
> If no comma, it means departure time only - except for the last stop :
> means arrival time only.
>
>
> Should we use 0-24-25 hour format ? (when a trip starts at 23:45 and
> finishes 30 minutes later at 0:15, which is sometimes written 24:15 in a
> gtfs. )
>
>
> Julien “djakk”
>
>
> Le sam. 3 nov. 2018 à 12:53, Jo  a écrit :
>
>> For buses it's exceptional they stay at a stop longer than strictly
>> necessary, so I think the arrival times should be optional. If the tag is
>> added, it should have the same amount of entries as the departures though.
>>
>> Sometimes I do see buses that 'linger' at stops, but that's usually
>> because they are ahead of their schedule by more than a few minutes.
>>
>> Jo
>>
>> Op za 3 nov. 2018 om 12:02 schreef djakk djakk :
>>
>>> Jo, I did not try yet, but I think there should be a departure timetable
>>> AND an arrival timetable (trains often stop several minutes). And this, per
>>> stop.
>>>
>>> The mapper sees a timetable at a bus stop, he puts it directly into a
>>> relation associating the bus stop and the route. This enables to partially
>>> map the line.
>>>
>>> The first stop has departure timetable only.
>>> The last stop has arrival timetable only.
>>> An intermediate stop has both.
>>>
>>>
>>> Julien « djakk »
>>>
>>>
>>> Le sam. 3 nov. 2018 à 11:38, Jo  a écrit :
>>>
>>>> I took it from the official timetables and generally this line doesn't
>>>> suffer too much from congestion. But yes. If the timetable shows bigger
>>>> variation in delay between stops over the day, then another method would be
>>>> necessary.
>>>>
>>>> Obviously this is what the operator plans to happen. In practice buses
>>>> will run later than their scheduled times. We have access to real time
>>>> information for each stop though. I think I'm going to add the direct urls
>>>> to the stops themselves.
>>>>
>>>> For the lines/routes a direct link to a url of this kind is probably
>>>> more helpful than trying to store all the detail:
>>>> https://www.delijn.be/nl/lijnen/lijn/3/301.
>>>>
>>>> But I'm trying to explore how we could add timetable information for
>>>> regions where this kind of service doesn't exist.
>>>>
>>>> Jo
>>>>
>>>> Op za 3 nov. 2018 om 11:22 schreef Mateusz Konieczny <
>>>> matkoni...@tutanota.com>:
>>>>
>>>>> So this assumes that bus travels for the same time between stops both
>>>>> during night and
>>>>> during rush hour?
>>>>>
>>>>> 3. Nov 2018 11:19 by winfi...@gmail.com:
>>>>>
>>>>> When done this way, the departures in the tags are for the stop with
>>>>> role 00:00.
>>>>>
>>>>> Jo
>>>>>
>>>>> Op za 3 nov. 2018 om 11:09 schreef Jo :
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'm looking into this timetable relation and how it could be
>>>>>> implemented:
>>>>>>
>>>>>> https://www.openstreetmap.org/relation/8885374/history
>>>>>>
>>>>>> This is for a simple line...
>>>>>>
>>>>>> I added all the stops of the route relation and added the most common
>>>>>> times to get from one to the next. I realise things can get even more
>>>>>> complex if these differentials change during the day due to congestion 
>>>>>> that
>>>>>> was planned for in the time tables.
>>>>>>
>>>>>> When done this way, it's not a timetable relation for each stop/route
>>>>>> pair.
>>>>>>
>>>>>> I'll try to do something similar for a more complicated situation.
>>>>>> (telescopic line, i.e. not all trips are the same length)

Re: [Tagging] Public Transport Timetables Proposal RFC

2018-11-03 Thread Jo
I created a few more for a more 'complicated' line, which changes in length.

Normal northbound:
https://www.openstreetmap.org/relation/8886015

Shortened northbound:
https://www.openstreetmap.org/relation/8886014

I used the same route relation twice, because for telescopic lines I only
mapped the longer variants.

Normal southbound:
https://www.openstreetmap.org/relation/8886013

Shortened southbound:
https://www.openstreetmap.org/relation/8886011

This one refers to another route relation than the previous one, as it does
something different for the last 2 stops, so the bus is ready to start
again on the northbound journey.

Last fare on Saturday evening only goes to the railway station:
https://www.openstreetmap.org/relation/8886012

So 5 extra relations to describe the whole timetable. To make this
manageable (and interpret what it really means in reality) we will need
dedicated tools though.

Now I'll try with a route that changes on Wednesdays, so not all weekdays
are the same, because school ends at noon on Wednesdays over here.

Polyglot

Op za 3 nov. 2018 om 14:01 schreef djakk djakk :

> Maybe we can put that optional piece of information inside the departures
> key : departures=7:40,7:45 ; 8:40,8:45 -> means the train or the bus
> arrives at the stop at 7:40 or 8:40 and leaves 5 minutes later.
>
> Arrival and departure time are separated by a comma, and different
> departures are separated by a semicolon.
>
> If no comma, it means departure time only - except for the last stop :
> means arrival time only.
>
>
> Should we use 0-24-25 hour format ? (when a trip starts at 23:45 and
> finishes 30 minutes later at 0:15, which is sometimes written 24:15 in a
> gtfs. )
>
>
> Julien “djakk”
>
>
> Le sam. 3 nov. 2018 à 12:53, Jo  a écrit :
>
>> For buses it's exceptional they stay at a stop longer than strictly
>> necessary, so I think the arrival times should be optional. If the tag is
>> added, it should have the same amount of entries as the departures though.
>>
>> Sometimes I do see buses that 'linger' at stops, but that's usually
>> because they are ahead of their schedule by more than a few minutes.
>>
>> Jo
>>
>> Op za 3 nov. 2018 om 12:02 schreef djakk djakk :
>>
>>> Jo, I did not try yet, but I think there should be a departure timetable
>>> AND an arrival timetable (trains often stop several minutes). And this, per
>>> stop.
>>>
>>> The mapper sees a timetable at a bus stop, he puts it directly into a
>>> relation associating the bus stop and the route. This enables to partially
>>> map the line.
>>>
>>> The first stop has departure timetable only.
>>> The last stop has arrival timetable only.
>>> An intermediate stop has both.
>>>
>>>
>>> Julien « djakk »
>>>
>>>
>>> Le sam. 3 nov. 2018 à 11:38, Jo  a écrit :
>>>
>>>> I took it from the official timetables and generally this line doesn't
>>>> suffer too much from congestion. But yes. If the timetable shows bigger
>>>> variation in delay between stops over the day, then another method would be
>>>> necessary.
>>>>
>>>> Obviously this is what the operator plans to happen. In practice buses
>>>> will run later than their scheduled times. We have access to real time
>>>> information for each stop though. I think I'm going to add the direct urls
>>>> to the stops themselves.
>>>>
>>>> For the lines/routes a direct link to a url of this kind is probably
>>>> more helpful than trying to store all the detail:
>>>> https://www.delijn.be/nl/lijnen/lijn/3/301.
>>>>
>>>> But I'm trying to explore how we could add timetable information for
>>>> regions where this kind of service doesn't exist.
>>>>
>>>> Jo
>>>>
>>>> Op za 3 nov. 2018 om 11:22 schreef Mateusz Konieczny <
>>>> matkoni...@tutanota.com>:
>>>>
>>>>> So this assumes that bus travels for the same time between stops both
>>>>> during night and
>>>>> during rush hour?
>>>>>
>>>>> 3. Nov 2018 11:19 by winfi...@gmail.com:
>>>>>
>>>>> When done this way, the departures in the tags are for the stop with
>>>>> role 00:00.
>>>>>
>>>>> Jo
>>>>>
>>>>> Op za 3 nov. 2018 om 11:09 schreef Jo :
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'm looking into this timetable relation and how it could be
>>>>>&g

Re: [Tagging] Public Transport Timetables Proposal RFC

2018-11-03 Thread Jo
For buses it's exceptional they stay at a stop longer than strictly
necessary, so I think the arrival times should be optional. If the tag is
added, it should have the same amount of entries as the departures though.

Sometimes I do see buses that 'linger' at stops, but that's usually because
they are ahead of their schedule by more than a few minutes.

Jo

Op za 3 nov. 2018 om 12:02 schreef djakk djakk :

> Jo, I did not try yet, but I think there should be a departure timetable
> AND an arrival timetable (trains often stop several minutes). And this, per
> stop.
>
> The mapper sees a timetable at a bus stop, he puts it directly into a
> relation associating the bus stop and the route. This enables to partially
> map the line.
>
> The first stop has departure timetable only.
> The last stop has arrival timetable only.
> An intermediate stop has both.
>
>
> Julien « djakk »
>
>
> Le sam. 3 nov. 2018 à 11:38, Jo  a écrit :
>
>> I took it from the official timetables and generally this line doesn't
>> suffer too much from congestion. But yes. If the timetable shows bigger
>> variation in delay between stops over the day, then another method would be
>> necessary.
>>
>> Obviously this is what the operator plans to happen. In practice buses
>> will run later than their scheduled times. We have access to real time
>> information for each stop though. I think I'm going to add the direct urls
>> to the stops themselves.
>>
>> For the lines/routes a direct link to a url of this kind is probably more
>> helpful than trying to store all the detail:
>> https://www.delijn.be/nl/lijnen/lijn/3/301.
>>
>> But I'm trying to explore how we could add timetable information for
>> regions where this kind of service doesn't exist.
>>
>> Jo
>>
>> Op za 3 nov. 2018 om 11:22 schreef Mateusz Konieczny <
>> matkoni...@tutanota.com>:
>>
>>> So this assumes that bus travels for the same time between stops both
>>> during night and
>>> during rush hour?
>>>
>>> 3. Nov 2018 11:19 by winfi...@gmail.com:
>>>
>>> When done this way, the departures in the tags are for the stop with
>>> role 00:00.
>>>
>>> Jo
>>>
>>> Op za 3 nov. 2018 om 11:09 schreef Jo :
>>>
>>>> Hi,
>>>>
>>>> I'm looking into this timetable relation and how it could be
>>>> implemented:
>>>>
>>>> https://www.openstreetmap.org/relation/8885374/history
>>>>
>>>> This is for a simple line...
>>>>
>>>> I added all the stops of the route relation and added the most common
>>>> times to get from one to the next. I realise things can get even more
>>>> complex if these differentials change during the day due to congestion that
>>>> was planned for in the time tables.
>>>>
>>>> When done this way, it's not a timetable relation for each stop/route
>>>> pair.
>>>>
>>>> I'll try to do something similar for a more complicated situation.
>>>> (telescopic line, i.e. not all trips are the same length)
>>>>
>>>> Polyglot
>>>>
>>>> Op za 3 nov. 2018 om 10:21 schreef Andy Townsend :
>>>>
>>>>>
>>>>> On 03/11/2018 04:55, djakk djakk wrote:
>>>>> > I do not see why timetables are hard to maintain ? Most bus lines do
>>>>> > not change their schedules for years (even in big cities, Paris for
>>>>> > example). Because changing the schedule means buy a new bus and hire
>>>>> > new drivers.
>>>>> >
>>>>>
>>>>> OSM has been described as a "do-ocracy".  Basically, if you think that
>>>>> other people should do something why don't you do it in your area for
>>>>> a
>>>>> period of time (maybe a couple of months) to demonstrate that it is
>>>>> possible and practical?
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Andy
>>>>>
>>>>>
>>>>>
>>>>> ___
>>>>> Tagging mailing list
>>>>> Tagging@openstreetmap.org
>>>>> https://lists.openstreetmap.org/listinfo/tagging
>>>>>
>>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Public Transport Timetables Proposal RFC

2018-11-03 Thread Jo
I took it from the official timetables and generally this line doesn't
suffer too much from congestion. But yes. If the timetable shows bigger
variation in delay between stops over the day, then another method would be
necessary.

Obviously this is what the operator plans to happen. In practice buses will
run later than their scheduled times. We have access to real time
information for each stop though. I think I'm going to add the direct urls
to the stops themselves.

For the lines/routes a direct link to a url of this kind is probably more
helpful than trying to store all the detail:
https://www.delijn.be/nl/lijnen/lijn/3/301.

But I'm trying to explore how we could add timetable information for
regions where this kind of service doesn't exist.

Jo

Op za 3 nov. 2018 om 11:22 schreef Mateusz Konieczny <
matkoni...@tutanota.com>:

> So this assumes that bus travels for the same time between stops both
> during night and
> during rush hour?
>
> 3. Nov 2018 11:19 by winfi...@gmail.com:
>
> When done this way, the departures in the tags are for the stop with role
> 00:00.
>
> Jo
>
> Op za 3 nov. 2018 om 11:09 schreef Jo :
>
>> Hi,
>>
>> I'm looking into this timetable relation and how it could be implemented:
>>
>> https://www.openstreetmap.org/relation/8885374/history
>>
>> This is for a simple line...
>>
>> I added all the stops of the route relation and added the most common
>> times to get from one to the next. I realise things can get even more
>> complex if these differentials change during the day due to congestion that
>> was planned for in the time tables.
>>
>> When done this way, it's not a timetable relation for each stop/route
>> pair.
>>
>> I'll try to do something similar for a more complicated situation.
>> (telescopic line, i.e. not all trips are the same length)
>>
>> Polyglot
>>
>> Op za 3 nov. 2018 om 10:21 schreef Andy Townsend :
>>
>>>
>>> On 03/11/2018 04:55, djakk djakk wrote:
>>> > I do not see why timetables are hard to maintain ? Most bus lines do
>>> > not change their schedules for years (even in big cities, Paris for
>>> > example). Because changing the schedule means buy a new bus and hire
>>> > new drivers.
>>> >
>>>
>>> OSM has been described as a "do-ocracy".  Basically, if you think that
>>> other people should do something why don't you do it in your area for a
>>> period of time (maybe a couple of months) to demonstrate that it is
>>> possible and practical?
>>>
>>> Best Regards,
>>>
>>> Andy
>>>
>>>
>>>
>>> ___
>>> 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] Public Transport Timetables Proposal RFC

2018-11-03 Thread Jo
When done this way, the departures in the tags are for the stop with role
00:00.

Jo

Op za 3 nov. 2018 om 11:09 schreef Jo :

> Hi,
>
> I'm looking into this timetable relation and how it could be implemented:
>
> https://www.openstreetmap.org/relation/8885374/history
>
> This is for a simple line...
>
> I added all the stops of the route relation and added the most common
> times to get from one to the next. I realise things can get even more
> complex if these differentials change during the day due to congestion that
> was planned for in the time tables.
>
> When done this way, it's not a timetable relation for each stop/route pair.
>
> I'll try to do something similar for a more complicated situation.
> (telescopic line, i.e. not all trips are the same length)
>
> Polyglot
>
> Op za 3 nov. 2018 om 10:21 schreef Andy Townsend :
>
>>
>> On 03/11/2018 04:55, djakk djakk wrote:
>> > I do not see why timetables are hard to maintain ? Most bus lines do
>> > not change their schedules for years (even in big cities, Paris for
>> > example). Because changing the schedule means buy a new bus and hire
>> > new drivers.
>> >
>>
>> OSM has been described as a "do-ocracy".  Basically, if you think that
>> other people should do something why don't you do it in your area for a
>> period of time (maybe a couple of months) to demonstrate that it is
>> possible and practical?
>>
>> Best Regards,
>>
>> Andy
>>
>>
>>
>> ___
>> 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 Timetables Proposal RFC

2018-11-03 Thread Jo
Hi,

I'm looking into this timetable relation and how it could be implemented:

https://www.openstreetmap.org/relation/8885374/history

This is for a simple line...

I added all the stops of the route relation and added the most common times
to get from one to the next. I realise things can get even more complex if
these differentials change during the day due to congestion that was
planned for in the time tables.

When done this way, it's not a timetable relation for each stop/route pair.

I'll try to do something similar for a more complicated situation.
(telescopic line, i.e. not all trips are the same length)

Polyglot

Op za 3 nov. 2018 om 10:21 schreef Andy Townsend :

>
> On 03/11/2018 04:55, djakk djakk wrote:
> > I do not see why timetables are hard to maintain ? Most bus lines do
> > not change their schedules for years (even in big cities, Paris for
> > example). Because changing the schedule means buy a new bus and hire
> > new drivers.
> >
>
> OSM has been described as a "do-ocracy".  Basically, if you think that
> other people should do something why don't you do it in your area for a
> period of time (maybe a couple of months) to demonstrate that it is
> possible and practical?
>
> Best Regards,
>
> Andy
>
>
>
> ___
> 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 Timetables Proposal RFC

2018-10-31 Thread Jo
Op wo 31 okt. 2018 om 09:31 schreef djakk djakk :

> Hello ! I think it’s a good idea to “replace” GTFS files with OSM data.
>
> In OSM there is already half of the GTFS (the relations that describes
> stops and route).
>

We have the part of GTFS that makes sense to have in a geographical
database. That's only 10-15% of what is found in a GTFS file though, not
50%. We're already struggling to keep that part up-to-date. I'm not
convinced either it would be a good idea to try and add timetable data into
OSM. Doing it in full detail gets very complex, very fast, due to all the
exceptions and not doing it in full detail is not useful to begin with.
For irregular services like school buses or market buses, it may make sense
to use an opening hours scheme as they only function 2 times a day or 1 day
per week. For metro lines it may make sense to indicate whether to expect 1
every 5 or 1 every 15 minutes.

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


Re: [Tagging] Draft Proposal: Default Langauge Format

2018-09-27 Thread Jo
>
> As a Flemish person, I rather have the name of the street pronounced
> in Dutch in Brussels than in the 2 languages as is now the case. This
> is probably one of the complications
> 


This is especially true because the pronunciation rules for both languages
differ significantly. I have OsmAND set to English and it manages to
pronounce both languages wrong... But the same would be true when setting
it to either nl or fr. It would be better to only use name:nl or name:fr
instead of name for Brussels. But that is something to solve in OsmAND.

When I'm looking at the map, I prefer to see both names though, as they are
now. So I totally agree with Paul Allen's message. It depends on the use
one wants to make of the data.

Ideally we know what language the name tag is in and even more ideally we
would have IPA transliterations for those cases added to the DB where
automated text to speech consistently gets it wrong. Of course that has its
own problems, as not everyone pronounces words or names the same way.

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


Re: [Tagging] Draft Proposal: Default Langauge Format

2018-09-26 Thread Jo
I would expect Frederik to be even more disappointed if we were to first
duplicate name to name:XX and then have another round of edits to remove
name.

At some point JOSM's valdiator was telling me to add name:language, so I
did. That's where some of those Belgian entries probably come from for the
objects I had been changing for other reasons.

Polyglot

Op wo 26 sep. 2018 om 12:02 schreef Christoph Hormann :

> On Wednesday 26 September 2018, Frederik Ramm wrote:
> >
> > I added a comment on avoiding duplication - I would be very unhappy
> > if every feature on the planet that currently only has a name tag
> > would now be amended with an identical name:xx tag just because xx is
> > the language spoken in that country!
>
> Yes, this is probably the key obstacle to all attempts to abolish the
> plain name tag (with all its inherent problems) because at least
> temporarily (until a new name tagging system is fully established)
> there would be need to keep the old name tag and any adoption of the
> new system would require duplication.  There is no solution for this,
> it is an inevitable side effect of actually solving the naming problem
> in OSM instead of just doctoring around the symptoms.
>
> But the good news is that both the proposal of Joseph and my suggestion
> would allow a simple an reliable fallback to the current tagging scheme
> so once most data users are capable of interpreting the new scheme you
> could smoothly convert the tagging feature by feature without
> duplication and without a negative effect on usability.
>
> The big problem of this approach however is that you would need to
> convince data users to implement interpretation of a new tagging system
> up-front without the database containing significant amounts of data
> where this would be useful for.  This is not just buying the cat in a
> sac, it is like building a home for the cat without having seen it yet.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> 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] Draft Proposal: Default Langauge Format

2018-09-19 Thread Jo
Every street in Brussels HAS a name:fr tag. They also ALL have a name:nl
tag.

An IPA representation also needs information about the language it is for.
A name, even spelled with the exact same characters will be pronounced
differently by a French speaker compared to a Ducht speaker. Sometimes very
differently, sometimes it's simply a matter of which syllable to stress.

Polyglot

Op wo 19 sep. 2018 om 04:43 schreef Joseph Eisenberg <
joseph.eisenb...@gmail.com>:

> Paul,
>
> Thank you for your comments.
> Have you read the complete Proposal page
> ?
> Perhaps I need to improve the wording to clarify some of your concerns
>
> >”I'd rather have local languages mapped rather than the language the
>>> renderer 'should' use.”
>>>
>>> By recording each name in a separate “name:=*” tag, database users
>>> and map makers will be able to pick the best name for their audience.
>>>
>>
>> The best name for the audience is the one which matches the signage.  It
>> does me no good to see an English
>> translation of a Russian street sign.
>>
>
> This is true if your database use case is rendering a map for a local
> audience. That's why the Openstreetmap Carto style renders names this way.
> This proposal will not change the way names are rendered on the standard
> map, except in the rare case where, for example, "name:fr=*" is present on
> a feature in France but the "name=*" tag is missing. In this case it will
> now render properly.
>
> But not all names are street or shop names. There are internationally know
> features, like Mt Everest and the Yellow River, which have well-known names
> in many names, which are quite different than the locally used name. Take a
> look at the current rendering of Nepal or China. The Openstreetmap Carto
> style is useful if you are in Nepal and want to find a sign point you
> towards Mt Everest, but a person sitting at their computer in Brazil will
> have trouble finding the mountain on the standard map style.
>
> The French style already renders names in French preferentially, but this
> loses the information about the locally used name. I agree that this is a
> problem!
> But with the current use of names, it's not possible to make an
> international map style that shows French names and the locally name at the
> same time.
> If you try to render "name:fr=*" and "name=*" together, you'll render the
> French name twice for every street in Brussels
>
>
>> The only thing the map should render is the name as it is displayed on
>> signage.
>>
>
> For local routing yes, for Openstreetmap Carto yes, but all applications?
> Not always
>
>
>> It would also be useful if the IPA characters representing how a local
>> would pronounce that name is present so applications could feed that
>> to text-to-speech.
>>
>
> Yes! IPA is a great idea. I believe "name:ipa=*" could work for this. Want
> to write up a proposal? :-)
>
>
>> It is also somewhat useful, for multilingual signage, to use name:xx and
>> name:yy to hold the individual
>> language components of that name.
>>
>
> You've got it! That's exactly what we want to encourage. If every street
> in Brussels has name:fr=xx and name:nl=yy, the French map style could
> render both.
> ( Or being the French, they might just render "name:fr=yy", but
> there's nothing to be done about that. )
>
>>
>> The local name still needs to be specified so that database users know
>>> what name or names are actually used “on the ground” vs foreign names. The
>>> default language format tag makes this possible, but separates this
>>> function from the name=* tag. And the proposal includes a language:local
>>> tag so that all local names can be shown, even those that are less common
>>> or in a minority language.
>>>
>>
>> No, no and thrice no.
>>
>
> ??? What are you objecting to here? The "language:local=" tag?
> This will not be rendered by Openstreetmap Carto style or anyone really.
> It just lets database users that certain languages are actually locally
> used names, vs foreign names.
>
> For example, Puncak Trikora (id) / Wilhelmina Top (nl) / Mount Trikora
> (en) is the 2nd or 3rd tallest mountain in Indonesia. It's currently tagged
> with name="Puncak Trikora", which is appropriate, because that's the name
> used in Indonesian, the official langauge, and would be recognized by most
> people in the country. But there is also a local name in the Lani language,
> which is only known to people who live closest to the mountain and isn't
> used on any offical signs. This language:local= tag would show that the
> Lani name for the mountain is in fact a local name, not a foreign language
> name.
>
> It's probably not a tag that will be used much in Europe, where minority
> languages often have official recognition and signage, but it will be quite
> helpful in parts of the world with many languages, particularly for
> mountains and rivers that may have foreign names from the 

Re: [Tagging] Slow vehicle turnouts

2018-09-13 Thread Jo
I have been ignoring bus bays for several years and I'm happy we now have a
way to tag them. These extra lanes are very similar, so I'd say that is the
way to go for mapping them. No need for a preset, you'll find that the
double split map mode in PT_Assistant is a lot more practical to split a
way in 2 places at once.

British English seems to use passing place. So what about?

passing_place=right / left / both

Where both is unlikely, of course.

Polyglot

Op do 13 sep. 2018 om 16:46 schreef Dave Swarthout :

> Tod writes:
> >In California the narrow mountain roads will have “turn outs”. These are
> very short, basically just enough room for a >vehicle to pull over and stop
> to allow others to pass. These are signed in advance with something like
> “Turn out 500 ft >ahead”.
>
> These are tagged in OSM, according to the Wiki, as highway=passing_place
> and the use of the tag is restricted to nodes. The restriction is probably
> because those places are so short and nodes, except for the problem of
> directionality, as you and others point out, do the job well enough. But
> that tag won't work in my case because these are actual separate lanes with
> a significant length. Clearly, some sort of definitive tagging for ways is
> needed.
>
> Consequently, I've been ignoring turnouts in my own work although I've
> always felt they should be mapped. I wanted to get things right before
> settling on a scenario, writing a short JOSM preset to increase efficiency,
> and then proceeding to tag them.
>
> On Thu, Sep 13, 2018 at 9:15 PM Tod Fitch  wrote:
>
>> In California the narrow mountain roads will have “turn outs”. These are
>> very short, basically just enough room for a vehicle to pull over and stop
>> to allow others to pass. These are signed in advance with something like
>> “Turn out 500 ft ahead”.
>>
>> There are also “passing lane” signs for areas where an extra lane extends
>> long enough for slow vehicles to maintain their speed in the new right
>> lane. These are generally signed longer in advance, e.g. “passing lane 1
>> mi”.
>>
>> And on long grades like on the “grapevine” on I-5 between Bakersfield
>> there are slow vehicle lanes marked off with a solid white line that extend
>> for the full length of both up and down grades that are too steep for a
>> loaded HGV to handle at the normal flat land speed limit. All the ones I
>> can think of have reduced HGV speed limits.
>>
>> Reading through this discussion I have the feeling that some areas have
>> one or another of these features but not all three and are somehow assuming
>> that what they are familiar with covers all the cases. For myself, I add
>> slow vehicle lanes and passing lanes to the roadway along with any other
>> tagging (maxspeed:hgv, change:lanes, etc.) And for turn outs, I either
>> ignore them or put a node. Problem with a node is that the turn out is for
>> one direction of travel and nodes are not good for that.
>>
>> Cheers,
>> Tod
>>
>> On Sep 13, 2018, at 7:00 AM, Kevin  wrote:
>>
>> Here in Georgia (USA) I believe we call these types of lanes "passing
>> lanes".  But that's usually only in reference to the left lane.  You
>> generally stay to the right except to pass.
>>
>> https://www.dawsonnews.com/local/gdot-remove-hwy-53-passing-lane/
>>
>> Kevin
>>
>> On Wed, Sep 12, 2018 at 6:21 PM, Dave Swarthout 
>> wrote:
>>
>>> >You say "turnout".  But physically, is it just an additional lane that
>>> >appears, and (more or less) one is obligated to move right one lane into
>>> >it if you're in the way?
>>>
>>> Exactly. I explained this several posts ago. It is an additional lane,
>>> running for perhaps a quarter mile, sometimes longer, that any vehicle
>>> which is holding back some number of other vehicles is obligated to use so
>>> that those following vehicles may pass. The reason I used the term
>>> "turnout" is because the signage erected by the Alaska DOT uses that term,
>>> as in, "Slow Vehicle Turnout Ahead 1500 feet".
>>>
>>> I see polyglot is ready to add some sort of processing to JOSM's
>>> PT_Assistant plugin if only we can decide what to call such lanes in OSM. I
>>> think the term slow_vehicle would work just fine.
>>>
>>> Dave
>>>
>>> On Thu, Sep 13, 2018 at 12:11 AM Jo  wrote:
>>>
>>>> A few months ago bus_bay=left|right|both was voted. For me this is
>>>> similar, albeit over a longer distance.
>>>>
>>>> extra_lane_for_slow_moving_traffic

Re: [Tagging] Slow vehicle turnouts

2018-09-12 Thread Jo
A few months ago bus_bay=left|right|both was voted. For me this is similar,
albeit over a longer distance.

extra_lane_for_slow_moving_traffic_to_compulsory_halt_to_let_other_traffic_pass_by=left|right|both
?

If you figure out which tag to use, we'll add it to the double split map
mode of JOSM's PT_Assistant plugin.

Polyglot

Op wo 12 sep. 2018 om 18:49 schreef Greg Troxel :

>
> > Again, I emphasize, this is not a crawler lane or a hill climbing lane.
> It
> > is a lane into which one pulls over to allow faster moving traffic to
> pass.
> > In fact, Alaskan law demands that any vehicle being followed by 5
> vehicles
> > must, at the first opportunity, allow those vehicles to pass. I doubt
> > anyone has ever been ticketed for this offense but nevertheless, the law
> > exists. Alaskan highways also have hill climbing lanes that are signed
> > "keep right except to pass". Those lanes are not the same as this one.
>
> Sorry, didn't get that this is not climbing lane (my fault).   In New
> England, extra lanes that one would associate with "slow vehicle" are
> 99% on hills.
>
> > Perhaps "slow_moving" isn't the best term for this sort of highway
> turnout
> > but it does the job.
>
> You say "turnout".  But physically, is it just an additional lane that
> appears, and (more or less) one is obligated to move right one lane into
> it if you're in the way?
>
> Do any routers do anything?  An example of how the data would be used,
> or how you think it would be used in an ideal future might be
> illuminaing.   Perhaps one's car computer could notice from forward
> radar that there is obstructing traffic and query osmand and give you a
> notification that the road becomes multilane in some distance, so you
> can get ready to blink to get the obstructor to move over if they stay
> left?   In that case, I wonder about the difference between a change to
> two lanes (perhaps because the row is wide enough and the long-term plan
> is 2) and a specific place like you describe.
> ___
> 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] routes with double use hiking and bicycle

2018-09-02 Thread Jo
My reaction was to how I read your message, it seemed like you would create
2 route_master relations and use those as members in a route relation.

For foot and bicycle relations it is possible to use sub relations for
parts in common between multiple routes, or if one route is designated
separately but is part of a 'superroute', but if I understood correctly for
that case both would be route relations.

That's not what this case is about is about though.

If the renderers and routers can cope with it, simply use a semicolon
between the tags, in case the members are exactly the same. If not, ask
them to update their software logic. In that case one route relation for
multiple 'modes of transport' suffices and we can keep things simple.

Polyglot



Op zo 2 sep. 2018 om 15:05 schreef Paul Allen :

> On Sun, Sep 2, 2018 at 1:53 PM, Jo  wrote:
>
>> In public transport:
>>
>
> Walking and cycling routes are not public transport.  Nevertheless
> (according to the wiki) route masters can be used
> with them.
>
> 1 (one) route_master relation for the line
>>
>> 1 or more (typically 2) route relations for the variations in itinerary.
>>
>
> I don't understand what point you're trying to make.  Or how those
> sentences contradict the idea of using a route
> master to cope with the variations of walking and cycling.
> Unconventional, yes, but you're the person who invented
> the reverse role for routes, so you don't let conventions bind you.  If
> the walking and cycling route weren't exactly
> identical (as is often the case) but largely corresponded, would a route
> master be appropriate then?  If not, why
> not?  It's a route from A to B with variants.
>
> It was just a thought, anyway.  As I said, I didn't think through all the
> ramifications.  But nothing you've said so far
> convinces me the idea is wrong.
>
> --
> Paul
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] routes with double use hiking and bicycle

2018-09-02 Thread Jo
In public transport:

1 (one) route_master relation for the line

1 or more (typically 2) route relations for the variations in itinerary.

Jo

Op zo 2 sep. 2018 om 13:59 schreef Paul Allen :

> On Sun, Sep 2, 2018 at 12:41 PM, Jo  wrote:
>
>> You are inverting how route_master relations are used in public
>> transport. There the route master represents a line, and our route
>> relations represent the itineraries (all the variations).
>>
>
> Variant 1: you can walk.
>
> Variant 2: you can cycle.
>
> I don't see how that differs significantly from variant 1 = "A B C D" and
> variant 2 = "A B D."  They are all ways of getting from A to D.
>
> To put it another way, how would you handle a bus route with two operators
> who use different service numbers and names for the same route?
>
> Creative abuse of the rules is fun.  Ask any company using tax avoidance
> schemes, like Google, Apple, etc.
>
> --
> Paul
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] routes with double use hiking and bicycle

2018-09-02 Thread Jo
You are inverting how route_master relations are used in public transport.
There the route master represents a line, and our route relations represent
the itineraries (all the variations).

Polyglot

Op zo 2 sep. 2018 om 13:35 schreef Paul Allen :

> On Sun, Sep 2, 2018 at 10:02 AM, Volker Schmidt  wrote:
>
>> There are routes out there that can be used by bicycle and on foot. Up tp
>> now I have classified them as one or the or the other, tagging according to
>> the prevalent use. This is unsatisfactory and, strictly speaking, not
>> corresponding to the principle of on-the-ground-truth.
>>
> [...]
>
>> The formally correct solution is "route=hiking;bicycle", and
>> network=lwn;lcn ecc
>> but this tagging is discouraged [1] and is flagged as error by JOSM, and
>> I suspect that it also not supported by data users, as it is not documented
>> anywhere.
>>
>
> The semi-colon is semi-deprecated, nevertheless it is the standard method
> of indicating that a tag has multiple
> values even if a particular tag does not explicitly say it can be used.
>
> I wouldn't worry about validators flagging it as an error.  By the nature
> of things they always lag behind new
> tagging.  JOSM flagging it as an error is only a serious problem if it
> refuses to let you save it.
>
> As for data consumers, maybe this would work (I haven't thought through
> all the ramifications).  Create a route
> with route=hiking;bicycle.  Then create two route masters, one with
> route_master=hiking and the other with
> route_master=bicycle; each route master includes the common
> route=hiking;bicycle.  This might solve some
> problems.  It will also likely cause different problems.
>
> The alternative, of course, is to use JOSM to clone the route, set one
> copy to route=hiking and the other copy to
> route=bicycle.  But that will be a pain in the bum to maintain the route
> changes.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] routes with double use hiking and bicycle

2018-09-02 Thread Jo
I would also think that the bicycle part would be somewhat different (more
split due to oneway traffic for bicycles on cycleways, whereas foot routes
can take the shortest path in both directions), so I think the best
approach is 2 route relations with quite some overlap.
It is a bit annoying that you then have 2 OSM objects for the same real
world 'concept' and I'm afraid there is no completely satisfying solution
for this.
Over here in Belgium bicycle routes and foot routes are always
'segregated'. The numbered foot route networks are also at a more granular
scale than the numbered cycle route networks.

Polyglot

Op zo 2 sep. 2018 om 11:27 schreef Yves :

> Why don't you Tage separate relations?
> Yves
>
> Le 2 septembre 2018 11:02:39 GMT+02:00, Volker Schmidt 
> a écrit :
>>
>> There are routes out there that can be used by bicycle and on foot. Up tp
>> now I have classified them as one or the or the other, tagging according to
>> the prevalent use. This is unsatisfactory and, strictly speaking, not
>> corresponding to the principle of on-the-ground-truth.
>>
>> I would like to distinguish between
>>
>>- routes that are exclusively hiking (containing ways that are
>>off-limits for bicycles)
>>- routes that are exclusively for cycling (containing ways that are
>>not suitable for pedestrians)
>>- routes that are intended for double use
>>
>> The formally correct solution is "route=hiking;bicycle", and
>> network=lwn;lcn ecc
>> but this tagging is discouraged [1] and is flagged as error by JOSM, and
>> I suspect that it also not supported by data users, as it is not documented
>> anywhere.
>> In my part of the world (Northern Italy) we have plenty of mixed-use
>> routes, which is in most cases already reflected in their name " percorso
>> ciclo-pedonale ".
>>
>> I suppose that this has been discussed in the past, and apologize if I
>> did not find  (or forgot) where.
>>
>> [1] https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator
>>
>> ___
> 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] horse mounting/dismounting steps

2018-08-28 Thread Jo
I found some more examples:

https://www.pathsforall.org.uk/pfa/creating-paths/think-different.html
https://www.pathsforall.org.uk/pfa/creating-paths/to-ride-or-not-to-ride.htmlhttps://www.pathsforall.org.uk/pfa/lowland-paths-guide/horse-mounting-blocks.html


I would be more specific and call them

man_made=horse_mounting_steps

Polyglot

Op di 28 aug. 2018 om 02:36 schreef Warin <61sundow...@gmail.com>:

> Hi,
>
> From a discussion on the GB list, these horse mounting/dismounting
> steps/blocks exist and people want to tag them.
>
> They certainly help get on and off a horse!
>
>
>
>  http://85a.co.uk/images/little_hereford7_960x800.jpg
>
>  http://85a.co.uk/images/little_hereford8_960x500.jpg
>
> 
> 
> How to tag them?
>
> Key?
> amenity
> historic
> man_made
>
> I'm inclined to man_made as the feature may not be 'historic'.
> And I'm not in favour of the less specific key of amenity.
>
> Value?
>
> mounting_block
> mounting_steps
>
> I think I prefer steps.
>
> Any thoughts?
>
> ___
> 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] What is a VTC car in OSM ?

2018-08-21 Thread Jo
Vehículos de Turismo con Conductor

Op wo 22 aug. 2018 om 00:49 schreef Steve Doerr :

> On 21/08/2018 09:55, José G Moya Y. wrote:
> > VTC is how rental cars with professional driver are called in Spain. I
> > think the rest of the thread clarifies this: It is the Spanish name
> > for Uber, Cabify and other companies that provide private transport
> > services but are not taxis (their cars are not equipped with taxi meter).
> >
>
> But surely it stands for something? A word beginning with V, a word
> beginning with T, and a word beginning with C? What are those words?
>
>
> --
>
> Steve
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
> ___
> 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] access:disabled... yes or designated?

2018-08-16 Thread Jo
you mean it must be tagged:

access=no
+exceptions
?

designated is an odd word. I started to understand it as signposted as
such, or clear from road markings.

but it's not the meaning it has in designated driver, where it means
"assigned with a specific role/responsability"

Op do 16 aug. 2018 om 23:59 schreef Warin <61sundow...@gmail.com>:

> On 17/08/18 07:46, Martin Koppenhoefer wrote:
> >
> > sent from a phone
> >
> >> On 16. Aug 2018, at 23:35, seirra  wrote:
> >>
> >> should cases where yes was used be corrected to designated? or should
> it be considered a stylistic choice?
> >
> > generally, it doesn’t work very well, because you want to express who
> can park there not who can access the lot. It should be “only” or
> “designated” because yes does not exclude others, while only does and
> designated tends to do.
> >
>
> For OSM .. to exclude others it should it not be tagged
>
> access=no
>
> then
>
> disabled=yes/designated to accept disabled?
>
>
> ___
> 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] Slash, space, or spaced hyphen in multi-lingual names

2018-08-11 Thread Jo
It's actually funny how these things go. Several years ago, mappers asked:
How can we map multilingual names. We told them: In Brussels we do it with
a spaced hyphen.

Oh thank you, we'll do it in a different way.

Several years later, people wonder why there are different ways for doing
things and attempt to 'standardise' these separators.

Polyglot



Op za 11 aug. 2018 om 09:09 schreef Martin Koppenhoefer <
dieterdre...@gmail.com>:

>
>
> sent from a phone
>
> > On 11. Aug 2018, at 06:13, Marc Gemis  wrote:
> >
> > I find it hard to understand why non-Belgians try to change a rule
> > that is accepted by the Belgian community. The name field contains the
> > name of the object as known by the local people. Not what an
> > Englishmen or anyone else knows the place as. There is no 1 name,
> > there are multiple names that have to be placed in 1 field. We could
> > have chosen a semi-colon, as dash, or a any other separator. We chose
> > " - ".
>
>
> nobody questions the local names, the discussion is about the separator,
> which has nothing to do with the on the ground situation AFAIK, because
> there this is solved typographically (different line or different
> font(size)).
>
> Using the same separator for the same thing (several names in different
> languages) is a general thing that could be done the same on a global
> level, it’s not something each local community must decide on their own (if
> they did, how it is now, there’s not much harm)
>
>
> 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] Slash, space, or spaced hyphen in multi-lingual names

2018-08-10 Thread Jo
What if the street sign said:

St Francis St.

would you be putting that exactly as is in the name tag?

I would put

Saint Francis Street

in it.

What if there are 3 signs, one with
St Francis St.
Saintt Francis St.
St Francis Street

It may be a longer street, it may be that time passed by between when those
signs were placed. But this does happen.

Are you reatlly going to put
name=St Francis St./Saintt Francis St./St Francis Street

to cover all your bases?

It's exactly the same situation. You're allowed to use some amount of your
brain power to get from what you find  on the signs before adding the
contents to OSM.

Op za 11 aug. 2018 om 01:05 schreef Paul Allen :

>
> On Fri, Aug 10, 2018 at 11:38 PM, Jo  wrote:
>
>> Fortunately all streets in Brussels are already mapped, based on official
>> data from Urbis. So the person from Biel who would prefer to put / in those
>> names doesn't need to to so anymore.
>>
>> There are definitely street name signs which are wrong. It would be
>> absurd to copy that wrong text into the name tags. It's not so wrong that
>> is something completely different.
>>
>> Besides many street name signs in Brussels are like this:
>>
>> Avenue
>>   Simon Bolivar
>>  laan
>>
>> Even if that is a spelling error in itself.
>> name=Avenue Simon Bolivar - Simon Bolivarlaan
>> name:nl=Simon Bolivarlaan
>>
>> words glue together in Dutch, like they do in German.
>>
>
> Given that situation I'd say the best way to map it is:
>
> name=Avenue Simon Bolivar Laan
> name:nl=Simon Bolivarlaan
> name:fr=Avenue Simon Bolivar
>
> Anyway, we don't want to put exactly what is on the street name signs in
>> our name tags.
>>
>
> Why not?  It's what is on the sign.  If that is what is on the sign then
> that is what is ought to be mapped.  Or maybe
> I should change roads into rivers because I prefer rivers and I don't want
> to map exactly what is on the ground.
>
>
>> It's simply not practical
>>
>
> Why?  String length isn't a data problem unless the string exceeds some
> arbitrary length allocated in the
> database schema.  It takes me a lot less time to type a long bilingual
> name for a highway than to trace the
> highway itself.
>
>
>> and it would very quickly become nonsensical.
>>
>
> If "name=Avenue Simon Bolivar Laan" is nonsensical then the street sign is
> nonsensical.  Complain to your
> local elected representative and ask him/her for legislation to change the
> naming conventions of street signs.
>
> I find it hard to understand why some mappers do not want to map reality.
> Unless it's because they wish the street
> signs were really monolingual.  There are people where I live who object
> to any use of English, should I cater to
> their whims by amending all names around here to remove the English text
> or should I map what is there?
>
> --
> Paul
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Slash, space, or spaced hyphen in multi-lingual names

2018-08-10 Thread Jo
Fortunately all streets in Brussels are already mapped, based on official
data from Urbis. So the person from Biel who would prefer to put / in those
names doesn't need to to so anymore.

There are definitely street name signs which are wrong. It would be absurd
to copy that wrong text into the name tags. It's not so wrong that is
something completely different.

Besides many street name signs in Brussels are like this:

Avenue
  Simon Bolivar
 laan

Even if that is a spelling error in itself.
name=Avenue Simon Bolivar - Simon Bolivarlaan
name:nl=Simon Bolivarlaan

words glue together in Dutch, like they do in German.

Anyway, we don't want to put exactly what is on the street name signs in
our name tags. It's simply not practical and it would very quickly become
nonsensical.

Jo



Op vr 10 aug. 2018 om 23:48 schreef Peter Elderson :

> if I were a renderer I would not try to parse/interpret a free format
> string. I would parse only clearly defined sections, where the separator is
> very very unlikely to occur in text strings. Space slash space might be
> suitable, but not if any context is required, context such as that it’s
> about language. So even if mappers and taggers decide to use eg
> spaceslashspace as a language separator or whatever other category of
> separator, I would still just render the full string including the
> separator string.
>
> As a mapper, I want to map whats visible on the ground. Street names are
> visible as strings on signs. I want to enter those without having to
> consult other sources. If I happen to have more detailed knowledge, I want
> to enter that in addition to the basics, not instead of. If the sign has
> one line which looks like it has variants within the one string, be it
> language varants, religious variants, or script variants, I still put the
> whole thing in the tag. I see no need for any kind of unification there,
> just copy the whole shebang.
>
> If (still as a mapper) I see multiple lines with equal font
> style/type/size, then I would probably summize that they are equal
> variants. In bilingual areas you can often be quite certain. Then I would
> concatenate using slash or space slash space. I would expect the renderer,
> any rendererer, not to break up the string but just render the whole thing
> as the name. Of course when name:xx tags are present, renderers may have
> rules for preference regarding name tags.
>
> If I were a data user, again I would not try to do anything with
> substrings of a free format string. Which is not the same as being against
> whatever people may wish to put in it, just you don’t build anything on
> free format strings.
>
>
> Mvg Peter Elderson
>
> > Op 10 aug. 2018 om 21:41 heeft marc marc 
> het volgende geschreven:
> >
> >> Le 10. 08. 18 à 19:28, Peter Elderson a écrit :
> >> If the sign shows two strings one line each, you will need
> >> interpretation and/or a glue character or glue string.
> >
> > in fact, what's the better glue character IS the question
> > at the begging of this thread.
> >
> > Currently, a Brussels resident reading a sign with 2 lines in Biel is
> > unable to fill in the name field without making a mistake or without
> > first having to search the wiki to find the local convention, at least
> > if this mapper has guessed that he is in a bilingual area (which is not
> > always obvious when one is not able to recognize that the second line is
> > the same as the first line in another language).
> > On the other hand, an inhabitant of Biel is unable to map a street
> > in Brussels without making a mistake, for the same reason.
> >
> > In the same way as in osm we defined ";" as being the separator between
> > several values of the same key (with several exceptions), it would be
> > useful to define a separator between several lines of the same key.
> > Afterwards, it will be up to the different local communities to see
> > the interest or not, to use it.
> > but it would allow for example a contributor who adds a street to
> > Brussels in iD or Josm to have assistance from the application to tell
> > him how to encode this and make the possible link with the different
> > corresponding name:xx
> >
> > or to take a less personal example, what would be the ideal way to do
> > things in a bilingual city where nothing has yet been done ? does this
> > community need a 5th glue character different from the 4 others ?
> > or is there a way to discuss the advantages and disadvantages of the
> > 4 existing separators without falling into a sterile debate such as
> > "I don't live in a bilingual zone so bilingual zones must have to do
> > l

Re: [Tagging] Slash, space, or spaced hyphen in multi-lingual names

2018-08-10 Thread Jo
The renderers and ALL data consumers would then have to take that into
account.

Tagging for the renderer means: Using a inappropriate tag on an object such
that it renders in a colour or style the mapper prefers over correctly
tagging an object.

Putting 2 names in a name field where those 2 names have equal standing is
not mapping for the renderer. That is mere pragmatism while mapping, and
yes, we like to get our stuff rendered. Outsiders should already be glad we
were able to agree on a consistent ordering for those names. The normal
Belgian compromise for resolving this would be: make sure that fr - nl and
nl - fr are equally distributed in name tags, at all times...

The reason for not choosing Brussel/Bruxelles is that Brussel - Bruxelles
clearly shows that there are 2 names in there. Instead of one long glued
together string of characters. And of course, there are place names which
have - in them, Sint-Agatha-Berchem - Berchem-Sainte-Agathe, for example.
(When I write them, I put nl first, obviously, that's my first language,
and incidentally also the language that place was known as, until maybe 200
years ago, before it became officially bilingual)

Polyglot

Op vr 10 aug. 2018 om 12:12 schreef SelfishSeahorse <
selfishseaho...@gmail.com>:

> Maybe a possible solution to get rid of name=* tags containing names
> in multiple languages would be to add the information about which
> languages are spoken in a particular region to its boundary relation
> (e.g. spoken_languages=de;fr to the municipality boundary of
> Biel/Bienne). However, the renderers would then have to take these
> relations into account.
>
> Cheers
> Markus
>
> On Thu, 9 Aug 2018 at 13:25, Marc Gemis  wrote:
> >
> > ]
> > > > p.s. It is not the first time this question pops up.
> > >
> > > That can be a sign that something is amiss.
> >
> > the previous times it popped up was not for consistency reasons, but
> > to do something on carto-css for osm.org
> > We do have multiple local tile sets for Belgium, where we do not have
> > that problem at all.
> >
> > As a Flemish person it's even annoying that software like OsmAnd
> > announces the name field and not name:nl
> > Nobody uses the composed FR-NL name in real live. You always use one
> > of the two depending on preference or situation.
> >
> > As someone suggested before, perhaps we should get rid of the usage of
> > name field for the default osm.org map and let the renderer decide
> > what (and how) to display names in multi-language areas based on
> > name:xx fields.
> > Let the local community assist in setting up those rules for carto-css
> > (e.g. French before Dutch), but the separator is decided by the map
> > maker.
> >
> > All that seems better than starting to change the name (and
> > addr:street) field of tens of thousands of objects just because
> > someone does not like the rendering on the default osm.org map.
> >
> > m.
> >
> > ___
> > 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] Slash, space, or spaced hyphen in multi-lingual names

2018-08-09 Thread Jo
Op do 9 aug. 2018 om 07:18 schreef Marc Gemis :

> Andy,
>
> Can you please elaborate a bit on the reason for your question ?
> Is it because you want a map with a uniform syntax for multiple names ?
> I assume it is not because  humans do not understand the meaning of
> one of the following forms Biel / Bienne, Biel/Bienne, Biel - Bienne,
> Biel (Bienne)
> Or do you want a uniform system for parsing ?
>
> The name field is just a label. If you want to know the exact name in
> a certain language you look at the name:xx field.
>
> p.s. It is not the first time this question pops up.  Not so long ago
> someone proposed to have a second field that indicates the format in
> which the name field is written.
>

Funnily enough they were not happy with

fr - nl

in that field though. But anyway, like Marc said, it's really easy to parse
using name:nl and name:fr. And if you really want, you can always put the
separator you prefer in between them in your rendering, or reverse the
order, or drop one of the languages.
Brussels is officially bilingual, so dropping 1 of the languages is not
exactly acceptable either, not for the general name tag anyway.

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


Re: [Tagging] Slash, space, or spaced hyphen in multi-lingual names

2018-08-08 Thread Jo
It's mostly our names did have hyphens, but none had hyphens with spaces
around them. Annoyingly we still get in trouble for those cases where both
sides of the street have different names... They exist, but they are rare
enough not to cause real headaches.

Op wo 8 aug. 2018 om 17:44 schreef Johnparis :

> Osmose generates an error if you use a slash. I don't see consistency as
> an advantage. It's a local decision.
>
> If the names use different writing systems (as in the HK example) a space
> is sufficient.
>
> Slashes do occur in names, but surely more rarely than embedded hyphens. I
> think the spaced hyphen is an effort to emulate the dash, which is not an
> ASCII character. A spaced double hyphen is better in that regard -- as in
> this sentence.
>
> On Wed, Aug 8, 2018, 17:22 Martin Koppenhoefer 
> wrote:
>
>>
>>
>> sent from a phone
>>
>> > On 8. Aug 2018, at 14:19, Andy Mabbett 
>> wrote:
>> >
>> > Greater consistency would surely be advantageous?
>>
>>
>> I prefer the slash, because hyphens occur in names, while I haven’t yet
>> encountered a name with slashes
>>
>> cheers,
>> Martin
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Documentation issues of PT tagging schemes

2018-08-04 Thread Jo
Hi Roland,

I made a fresh attempt to explain things as simple as it gets:

https://wiki.openstreetmap.org/wiki/User:Polyglot/Public_transport_proposal_for_simplification

I might expand this to how I see we could extend this tram and metro
mapping. For trains I would add such nodes for each sub section of a
platform, if there are trains (or parts of trains) that use only 'half a
platform', but I realise that is likely to be met with a lot of resistance.

For mapping the millions of bus stops and itineraries around the world, we
need a schema that is as simple as possible (and no simpler, like you
said). Any unnecessary complication/duplication simply doesn't scale.

I read your proposal, and you talk about platform_edges. No need for that
if there is a node for each direction of travel, even if the (separately
mapped) platform is shared in the middle of the railway lines. Such
platform are very likely to have names like platform 2 for one half, and
platform 3 for the other half.

Polyglot

Op wo 25 jul. 2018 om 19:25 schreef Roland Olbricht :

> Hi,
>
> > What I would like to see is how to map a Public Transport Route in
> > version 3 .. that has the bear minimum of things to have and the rules
> > that make the route valid.
>
> This is where the problem sits; the point of view of what a route is
> vary wildly. Few people are even willing to pinpoint and tell their
> personal definition.
>
> Things that exist under the notion of route:
>
> - Urban bus/tram/subway services (many stops, many departures, route
> taken always or almost always the same, route through the street grid
> practically fixed, often unchanged for years to decades)
>
> - Peak services, special routes to depot, school services (few
> departures, many stops, also many route variants, frequently changing,
> making it impractical to route them all)
>
> - Hail bus services: the bus is promised to serve a certain street and
> stops on hail (many departures, route taken always or almost always the
> same, route through the street grid practically fixed, often unchanged
> for years to decades)
>
> - Urban and regional train lines (many stops, many departures, route and
> platforms fixed). Those routes are often in parts or completely land marks.
>
> - Long distance train lines (many stops, many departures, route and
> platforms may or may not vary, can stop at a different platform of the
> same station for operational reasons)
>
> - Long distance bus services (few stops, few departures, route between
> stops often changing on the fly)
>
> - Ferry lines (often only two stops, completely different
> infrastructure)
>
> Further kinds of routes may exist. For example, some communties use
> virtual metro lines that connect station node to station node. This is
> most often because the communties lack the ressources to map the actual
> underground structures.
>
> I personally map only urban bus/tram/subway services and urban and
> regional train lines (and do not delete other routes). For these
> services it is sane to have marked the stops and the route on the grid.
>
> The route on the grid is straightforward: this is in any PT scheme a
> sequence of way members that together form a continuous trajectory. Hail
> sections get a special role for these members.
>
> The stop part is more tricky. I personally add one element for each stop
> where the bus/train is calling, using the role "platform". The member
> element should have the tag "name" set to ensure meaningful usage and
> pain-free editing of the route.
>
> The minimum required tags on the relation are "ref=",
> somtimes "name=", and "type=route" + "route=bus" for buses.
>
> Please do not forget that a more detailed explaination fits better on
> the transit list
> https://lists.openstreetmap.org/listinfo/talk-transit
> I would suggest to continue the discussion there, but Ilya has for
> unknown reason fear of the talk-transit list. It makes sense to give him
> an easy opportunity to answer.
>
> I read Ilya's proposal such that he wants to feature the virtual metro
> lines, at the expense of mandating to map hail services as empty
> relations. But it would be better if he tells us himself.
>
> Best regards,
> Roland
>
> ___
> 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] Let's get (quite) rid of units and their multiples in OSM values

2018-07-30 Thread Jo
There is a relatively simple solution that could satisfy everybody. (Except
maybe the people paying for the storage, but let's say tags are cheap)

For each tag that describes a measurement, add a counterpart tag with the
values converted to SI units, meter, second, km/h (or even m/s, everybody
equally out of their depth), Volt, Ah, Watt, kg.

Then it becomes trivial to compare them, and if you need them in another
unit, you can convert. It also makes it possible to validate the values.

Of course editors like JOSM and iD would help with adding those tags.

Polyglot

Op ma 30 jul. 2018 om 10:24 schreef Mateusz Konieczny <
matkoni...@tutanota.com>:

> 30. Lipiec 2018 01:00 od dieterdre...@gmail.com:
>
>  elevations should be with respect to the EGM96 sea level
>
>
> Where it is written on Wiki? Nobody is really following that.
> ___
> 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] Transport mode on platforms? (Was: Re: Documentation issues of PT tagging schemes)

2018-07-25 Thread Jo
Very soon after PTv2 was 'accepted' I understood that if we would ever
replace hw=bus_stop NODES with pt=platform, the mode of transport would
need to be added on these nodes.

Ever since it's a back and forth pulling between yes the mode of transport
can be added on them and NO the platforms don't need a mode of transport.

In the mean time, I'm not so sure that there is willingness to 'deprecate'
highway=bus_stop, not even sure if there ever was, and I guess there is no
real need for it etiher. The problem with that kind of thinking is that it
can lead to the conclusion the whole public_transport scheme is not needed
for the stops.

Now I don't mind using it, just like I wouldn't mind dropping it.

What I do mind is the use of multiple objects in the route relations to
represent the same stop and the perceived need to 'upgrade' stops from
nodes to ways/areas during their lifecycle if there are actual platforms
for passengers to wait on.

I created a 10 minute screencast showing some new functionality in
PT_Assistant, but more importantly it also shows the public_transport tags
are a bit confusing to some. In this case the stops mapped nicely as nodes
alongside the way got stop_position instead of platform as the value.

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

PT_Assistant's validator will tell you about this and JOSM will make it
easy to correct the situation.

After stopping the recording I went on to fix the from/to tags and adding a
route_master relation before uploading. But I wanted to keep the screencast
concise and to the point.

Polyglot

Op wo 25 jul. 2018 om 22:56 schreef SelfishSeahorse <
selfishseaho...@gmail.com>:

> Hi
>
> It seems that the only problem with PTv2 that remains is the rendering
> of public_transport=platform, i.e. whether public_transport=platform
> (and maybe public_transport=station too) should get the transport mode
> tag(s) (bus=yes/tram=yes/...).
>
> Note that the PTv2 proposal suggested to map the *stop position* 'as
> an icon depending of the vehicle type that is stopping at the
> position',[1] which may have led to some people mapping only
> stop_position's, others mapping only platform's and still others
> mapping stop_position's and platform's which in turn has led to
> complication and confusion.
>
> [1]:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport_v3
>
> As this question pops up every now and then, it might make sense to
> finish discussing this.
>
> I'm double posting this message on the transport mailing list, so that
> the discussion can continue there.
>
> Regards
> Markus
>
> On Wed, 25 Jul 2018 at 19:25, Roland Olbricht 
> wrote:
> >
> > Hi,
> >
> > > What I would like to see is how to map a Public Transport Route in
> > > version 3 .. that has the bear minimum of things to have and the rules
> > > that make the route valid.
> >
> > This is where the problem sits; the point of view of what a route is
> > vary wildly. Few people are even willing to pinpoint and tell their
> > personal definition.
> >
> > Things that exist under the notion of route:
> >
> > - Urban bus/tram/subway services (many stops, many departures, route
> > taken always or almost always the same, route through the street grid
> > practically fixed, often unchanged for years to decades)
> >
> > - Peak services, special routes to depot, school services (few
> > departures, many stops, also many route variants, frequently changing,
> > making it impractical to route them all)
> >
> > - Hail bus services: the bus is promised to serve a certain street and
> > stops on hail (many departures, route taken always or almost always the
> > same, route through the street grid practically fixed, often unchanged
> > for years to decades)
> >
> > - Urban and regional train lines (many stops, many departures, route and
> > platforms fixed). Those routes are often in parts or completely land
> marks.
> >
> > - Long distance train lines (many stops, many departures, route and
> > platforms may or may not vary, can stop at a different platform of the
> > same station for operational reasons)
> >
> > - Long distance bus services (few stops, few departures, route between
> > stops often changing on the fly)
> >
> > - Ferry lines (often only two stops, completely different
> > infrastructure)
> >
> > Further kinds of routes may exist. For example, some communties use
> > virtual metro lines that connect station node to station node. This is
> > most often because the communties lack the ressources to map the actual
> > underground structures.
> >
> > I personally map only urban bus/tram/subway services and urban and
> > regional train lines (and do not delete other routes). For these
> > services it is sane to have marked the stops and the route on the grid.
> >
> > The route on the grid is straightforward: this is in any PT scheme a
> > sequence of way members that together form a continuous trajectory. Hail
> > sections get a special role for these members.
> >
> > The stop 

Re: [Tagging] Documentation issues of PT tagging schemes (was: Re: Public Transport v3 — starting RFC)

2018-07-24 Thread Jo
The whole point of wanting to move to a simpler tagging scheme is to become
able to write simple to understand documentation.

Dropping the "v1" tags that some like to call 'deprecated' is not possible,
because then your stops don't render.
Replacing highway=bus_stop by public_transport=platform doesn't work
either, as you lose the information about the mode of transport,
bus=yes/tram=yes.

Dropping the public_transport tags on stops seems somewhat more
straightforward, but isn't completely either. (For example, I don't like
stop_position nodes and won't add them everywhere, but I had started to add
them where the itineraries terminate).

We're stuck.

When PT_Assistant stabilizes and becomes usable with josm_tested.jar, I'll
create some videos on what I consider to be "reasonable practices". That
will be in about 3 weeks, normally.

Polyglot

Op di 24 jul. 2018 om 15:56 schreef Leo Gaspard :

> My point of view, as a beginner in OSM who still hasn't understood how
> PTv1 and PTv2 are supposed to work (and thus didn't read this specific
> proposal, take this as generic comments on PT tagging in OSM):
>
>  1. Beginners are already at a loss, introducing a third (!) tagging
> scheme will just make things worse
>
>  2. If I were developer of an OSM tool, I'd be facepalming as soon as I
> saw the word “PTv3”
>
>  3. What is *really* needed is a clarification of what PTv[12] actually
> mean. This is first and foremost a documentation issue, not a tagging
> scheme issue.
>
>  4. If I understood correctly, it's possible to use PTv2 with as few
> tags as PTv1, but noone really understands it because the documentation
> is such a mess. So I think a proposal of “Clarification of the relative
> importance of tags in Public Transportation tagging” would be great.
>
>  5. Such a proposal would “just” improve the documentation for PTv2 and
> erase completely any reference to PTv1 from the wiki (or move it to a
> “historic tagging scheme, no longer to be used, but that could be
> necessary to understand for consumers until the migration has ended”
> section)
>
>  6. I personally spent at least half an hour (didn't count) trying to
> understand how to tag public transportation. After having tried to read
> the wiki, I just ragequit. The *documentation* is the issue for public
> transport, and adding a third tagging scheme will only make things worse.
>
>  7. Once the documentation about PTv1 will have vanished and about PTv2
> will be clear (and once the names PTv* will have disappeared to just be
> called “PT tagging”, in order to be less frightening for the beginner),
> *then* it would be interesting to discuss incremental modifications of
> the PT scheme. I guess that's where the changes you're proposing for
> “PTv3” (something that I think should not ever happen, would it be just
> for its name) would be interesting to integrate.
>
>  8. For my desiderata about the documentation, I think it should:
>  1. Be simple to read
>  2. Go from the simplest tagging elements to the most complex. For
> example, if I understood correctly PTv2 (ie. likely not), something like:
>  1. how to place public_transport=stop_position
>  2. how to make a route relation
>  3. how to make a master route relation
>  4. how to add public_transport=platform for people who feel like
> it
>  3. Fit in a single page (having to switch back and forth between
> dozens of pages for PT is just impossible to do while keeping focus)
>  4. Potentially, *at the end, once all important concepts will have
> been explained*, link to pages of individual transportation methods
>  5. Be written in a didactic style. Currently it's full of “There
> was this for a long time, and also that and that, but that is made
> possible by PTv2”. BUT WHAT SHOULD I DO? (sorry, that's not to be read
> yelling, just my internal thoughts when reading this kind of
> paragraphs). That's just not how we can make people do something, that's
> just a way to mix up everyone's mind but the minds of people who
> actively designed the scheme.
>  6. Give instructions as for what to do when the information is
> incomplete (eg. I saw a few stops but not the full route, but I've got a
> picture of the list of stations, what should I do?)
>
> Again, these are my 2¢ as a beginner who tried to understand the current
> way of tagging PT and just didn't understand it enough to try actually
> mapping with it. Also, obviously, I can say how I would want the page to
> be, but I can't do it myself because I just didn't manage to understand
> in a reasonable amount of time the PT tagging scheme. So I'll have to
> rely on you (yes, thou who readeth me) to write it, sorry!
>
>
> On 07/20/2018 10:48 PM, Ilya Zverev wrote:
> > Hi folks,
> >
> > As you might've noticed, in the past year there has been growing
> discomfort with the current Public Transport tagging schema. Of course, it
> brought order to our route relations, but also introduced a lot 

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

2018-06-23 Thread Jo
Op za 23 jun. 2018 om 10:26 schreef Peter Elderson :

> I think a bus stop node on the bus route is exactly what is needed to
> route people from anywhere to anywhere. You connect the pedestrian route to
> the bus route at that point. It does not really matter if the route
> includes a platform way, or a platform node, as long as it's part of the
> pedestrian route from the stop to any other routable way.
>

By on the bus route, you mean as part of the highway? If you do that, we
can't easily see on which side of the road the stop is located.

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


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

2018-06-23 Thread Jo
>
> You forgot to mention that  PTv2 complicates tagging
>
> and processing by requiring to add also bus=yes.
>
>
> As I do not like entering two tags where one fits well I continue
>
> and will continue and want to continue mapping bus stops
>
> solely as highway=bust_stop.
>
>
> bu stop is also not some obscure object what would justify
>
> complicating its tagging.
>

On the highway? or beside it? If beside it, I agree with you. When I add
your bus stops to a route relation using JOSM, they get a stop role though.
No biggie. But that was the reason why I started adding those
public_transport=platform tags to them, or at least that's why I continued
to do so.

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


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

2018-06-23 Thread Jo
It is not needed to have a platform. In that sense the
public_transport=platform is a misnomer for the node that represents the
bus/tram stop., but it is what was decided we would use.

Maybe we should come up with a v3 where that node gets a different value,
say public_transport=passengers_zone/area/spot. But it really doesn't
matter, as long as we don't interpret the word platform in
public_transport=platform literally when applied to nodes.

All that we need is a node that represents the bus or tram stop, which is
the only object that contains all its properties as tags and which is the
only object that needs to be added to the route relations.

Even for longer platforms the platform could be drawn as an area and the
approximate location whete the passengers are supposed to wait for (their
section of) the train can be marked with such nodes. Still no stop_postion
nodes needed on the railway.

The whole reason why we started marking the stations on the railway ways
themselves, is that all the way in the beginning a decade ago, we never
imagined the level of detail we are mapping at nowadays would be feasible.

So railways where represented with a single OSM way for several tracks. If
you work at that level of abstraction, it makes sense to add the stations
as nodes on those OSM ways. We continued doing this when we started mapping
each track as an OSM way and it spread to tram lines.

Nowadays it doesn't make sense anymore. What cam instead is that for some
unfathomable reason it is considered alright to duplicate details across
several objects and then more than one of these objects would need to be
added to the route relations.

It's not too late to rethink this and go for a solution that scales well
and is easy to understand for anyone.

By scaling well, I mean thatt the node that represents a stop, does not
need to be converted to a way at any moment in its lifetime.

For those stops that do have platforms, we can add them as separate
way/area objects. No need to add name/ref/etc to them, no need to add them
to the route relations. The nodes that represent the stops have that
function.

Polyglot

Op za 23 jun. 2018 om 10:07 schreef Markus Lindholm <
markus.lindh...@gmail.com>:

> On Fri, 2018-06-22 at 08:05 +, marc marc wrote:
> > Le 22. 06. 18 à 01:26, Yves a écrit :
> > > Why adding 'platform' where there's no physical platform?
> >
> > public_transport=platform describe where passagers wait
> > for a public transport.
> > if there is no dedicated area, use a node outside the road/rail
> > near the bus stop or near the railroad stop
>
> I believe this is one of the flaws of PTv2
>
> - The disconnect between tagging and reality.
>
> Probably the majority of the bus stops out there are without a platform
> of any kind. There is a pole, a shelter or a semaphore of some kind,
> but you couldn't find anything that anyone would point at and say
> 'That's the platform'
>
> /Markus
>
> ___
> 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

2018-06-22 Thread Jo
For access restrictions we had started by using psv=yes, but I guess few
people will read that as public services vehicle and another problem with
that is that is apparently includes taxis as well.

Personallly, I see a big difference between a way tagged as *=platform and
a node with that tag.

On a way it means the area where passengers are supposed to stand and which
usually is a bit higher, or explicitely created for those passengers. You
know it, when you see it.

On a node it means waiting area, where you can expect to be picked up by a
public transport vehicle. There could be pole, there could be a platform
(which can be drawn next to it), there could be a shelter, a vending
machine, a screen announcing when the vehicle will come, garbage cans,
benches. Or there could be nothing there at all, but the convention that
buses will alight and pick up passengers at that spot.

The platform node groups most of the properties of the bus stop, so it
makes sense to add it to the route relations. I'd like to see that it can
remain a node over the lifetime of such a bus stop. And for all the other
amenities near it, we can have separate objects.

This works just as well for bus stops as for tram stops and indeed, some
tram stops are served by buses as well.

it's that 'platform' node that gets bus=yes/tram=yes etc.

For the platform way/area mode of transport is far less important.

Maybe the platform node should have been called something else. Especially
since stop_position contains the word stop and some new mappers consider
that to be the correct tag for tagging the bus stop.

So yes, words are confusing and the way they have become defined in
OpenStreetMap even more so.

Polyglot

Op vr 22 jun. 2018 om 16:53 schreef Johnparis :

> Heh. Another example of the imperfectibility of language.
>
> Neither the GTFS specification nor the NetEx standard envisions any
> distinction between boarding-only and alighting-only points (or mixed ones,
> for that matter), and I have never encountered any bus route where such a
> distinction was made. Since the wiki is supposed to be descriptive, I
> have amended it accordingly, but of course there will still be other
> precisions to be made.
>
> I think Thorsten's description of the magic transfer is very accurate.
>
> One of the advantages of PTv2 over PTv1 is the ability to tag mutlimodal
> platforms. Tram platforms are frequently multimodal, but others can be as
> well. The tags used (not controversial) are public_transport = platform +
>  = yes, for one or more mode tags. The controversy referred to in
> another thread is that this duplicates (some of) the access=* mode tags, so
> there is a potential confusion between bus=yes when it is intended to be an
> access tag and bus=yes when it is a modal tag for public transport.
>
> I have previously gone on record as supporting "access:bus=yes" when
> access is meant, but I don't think that's very practical, and in the real
> world the conflict doesn't exist. (I suppose an alternative would be
> "public_transport:bus=yes" for such cases, which might make things simpler
> for parsing software, and maybe for editor software, but makes no
> difference otherwise that I can see.)
>
> John
>
>
>
>
>
> On Fri, Jun 22, 2018 at 2:35 PM, Martin Koppenhoefer <
> dieterdre...@gmail.com> wrote:
>
>>
>>
>> sent from a phone
>>
>> > On 22. Jun 2018, at 13:53, Johnparis  wrote:
>> >
>> > It's not always a waiting area, btw, sometimes it's reserved for
>> leaving the transportation device.
>>
>>
>> the definition for public_transport=platform is “The place where
>> passengers are waiting for the public transport vehicles.”
>> if the area is not used for waiting, you cannot tag it as platform, you
>> could use something like boarding_area
>>
>>
>> Cheers,
>> Martin
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2018-06-22 Thread Jo
Op vr 22 jun. 2018 om 10:10 schreef marc marc :

> Le 22. 06. 18 à 01:26, Yves a écrit :
> > Why adding 'platform' where there's no physical platform?
>
> public_transport=platform describe where passagers wait
> for a public transport.
> if there is no dedicated area, use a node outside the road/rail
> near the bus stop or near the railroad stop
>

Good, we agree thus far. Now if there is a dedicated area, map it as a way
or area and add:

highway=platform for bus stops
railway=platfomr for trams stops

maybe tactile_paving and wheelchair and a height.

BUT keep the node tagged as

highway=bus_stop
public_transport=platform
bus=yes
name=
ref=
route_ref=
operator=
network=
etc...

There is no need to "UPGRADE" from a node to a way/area. As this is not an
upgrade at all.

We can then use these highway=bus_stop nodes in the route relations and
each stop is represented in the route relations by 1 object. A single
object that has all the details for that stop. Nice and clean.

What I see happening is that a platform way and a stop_position node are
created, details are duplicated (maintenance nightmare)  and both are added
to the route relations.

There are still millions of bus stops that need to be mapped, we want to
have a way of mapping them that is as simple as feasible (without losing
information), but also that doesn't need transformations from nodes to ways
during the lifetime of the stops. A transformation that would also affect
all the route relations, and there are many of those as well, one for each
variation of a line.

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


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

2018-06-21 Thread 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

2018-06-21 Thread 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


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

2018-06-20 Thread Jo
I'll help you with those as well, as long as we can keep those dreadful
stop_position nodes out of it :-) (and tag the stops as nodes next to the
way).

but feel free to follow what the wiki seems to say, I'll probably help you
anyway, no worries. At the end of the day, you'll be the one who will be
maintaining those routes in the future. For the routes that I plan to
maintain, I want only a single node per stop in the route relations, which
has all the details exactly 1 time.

As I want to be able to see on which side of the street they are
positioned, I create them as nodes next to the way (so stop_position nodes
won't do for that purpose). A few years ago I asked which public_transport
tag to use for them, and the answer was platform, so I ran with that. Even
in those places where there was no actual platform. The biggest advantage
was that JOSM added them to route and stop_area relations with a platform
role. Apart from that it was probably a waste of storage bytes. The more I
think about it, the more Ilya's proposal to simply use highway=bus_stop
seems like the right thing to do.

And for those places where there are actual platforms those get tagged
highway=platform (no mode of transport, only maybe
wheelchair=yes/tactile_paving=yes and maybe a height). These are the ones
mentioned in this thread by the way, the ones that don't make sense to
change the rendering for.

What we were asking to change the rendering for are the supposed
replacements of highway=bus_stop/railway=tram_stop, but the more I think
about it, the less this seems necessary.

Polyglot

Op wo 20 jun. 2018 om 23:44 schreef 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.
>>
>
> I'll do it tomorrow.  I had a look earlier today and it was either broken
> before I looked or I broke it while trying
> to figure out how to use JOSM.  I'll post the link tomorrow after I've
> fixed it (or broken it even more).
>
> And yes, it's complicated.  The stop that is ignored the first time but
> used the second time is in the timetable
> but there isn't a shelter, there isn't a platform, there isn't a stop sign
> and there aren't any road markings.  The
> drivers I asked about it weren't sure exactly where it was.  It took a
> lengthy e-mail exchange with the head
> office before they finally admitted the stop existed and told me where
> they expected the drivers to stop.  At first
> it was "No, the bus doesn't stop there." and I had to rub their noses in
> the county council online timetable and
> their own online timetable.  They even tried declaring the whole route to
> be hail and ride, even in the town centre,
> to get around the problem.
>
> BTW, they have a couple of other routes that do similar things. :)
>
> --
> Paul
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2018-06-20 Thread Jo
Hi Paul,

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

Polyglot

Op wo 20 jun. 2018 om 23:11 schreef Paul Allen :

>
> On Wed, Jun 20, 2018 at 7:43 PM, 
> wrote:
>
>> Everything you write is no different between PTv2 and the old tagging
>> scheme.
>>
>>
>>
>> FIRST, all the stops, in order. THEN, all the ways that make up the
>> route, in order.
>>
>>
>>
>> As far as I’m aware, there hasn’t been a route tagging scheme before that
>> mixes the stops into the route before.
>>
>>
>>
>> The actual PTv2 proposal documents that quite well:
>>
>
> OK, at least that is clearer than the working pages of the wiki.  But I'm
> still having difficulty comprehending one thing.
> I have an actual route, and I'll designate segments of ways with letters
> (and simplify it a lot).  Platforms are mapped
> but stop positions aren't (somebody who thinks they shouldn't be there
> cleaned up after me).
>
> A  B  C  D  E  F M  N  B  C  D  E  F
>
> Starts at A, terminates at F.  It repeats B C D E F at the end of the
> route, but doesn't pass A.  There's a stop at A (start
> of the route). There's a stop at C which is ignored the first time the bus
> passes it but is stopped at (on request) the
> second time (and appears in the timetable). It stops at F both times.
>
> So the stops are going to be the ones at  A C F ... C F, in that order, in
> the relation.
>
> It's kinda hard for me to figure out what's going on from the relation,
> and I know the route.  Without stop positions
> it seems to me to be a lot of work for a router to figure out as well.  I
> think a typical consumer using the query tool
> would be completely baffled by the relation info returned.  But you're
> telling me this is correct?  If so, that's what
> I'll do.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] stop first or not and spliting or not the way for PT

2018-06-20 Thread Jo
I want to see a continuous line in JOSM's relation editor, so all the ways
in the relations connect at end points. So I'm splitting the ways so they
fit in the route relations.

Polyglot

Op wo 20 jun. 2018 om 20:52 schreef marc marc :

> Le 20. 06. 18 à 20:20, Paul Allen a écrit :
> > X --- bat street --- o --- cat street --- o --- dog street --- Z
>  > X is at the start of bat street, Z is at the end of dog street.
>  > Y is in the middle of cat street, not at either of
>  > its junctions with the other two streets.
>
> > X, Y, Z, bat street, cat street, dog street;
>
> > or X (which appears to be how it's ordered by default), bat
> > street, Y, cat street, dog street, Z;
>
> > or X, bat street, cat street, Y, dog street
>
> imho all are valid
>
> > Or should cat street be split at Y so I can have X,
> > bat street, cat street 1, Y, cat street 2, dog street, Z?
>
> you mustn't but you may.
> ___
> 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

2018-06-20 Thread Jo
1. I'm not confused.

2. I don't agree that highway=bus_stop nodes next to the ways should be
'UPGRADED' to ways or areas. We should keep those nodes AND add those nodes
and ONLY those nodes to the route relations.

3. If there happens to be an actual platform, we can keep mapping those as
highway=platform/railway=plattform on a way or area. Those are the ones
where I started to remove the public_transport=platform from.
highway=platform/railway=plattform
is perfectly fine for them.

Op wo 20 jun. 2018 om 19:24 schreef :

> I fully agree with everything marc said.
>
> But I think Jo's confusion comes primarily from the fact that
> public_transport=platform replaces BOTH highway=platform AND
> highway=bus_stop.
>
> So under the old tagging scheme you could have a highway=platform way or
> area, AND a highway=bus_stop node.
>
> In places where there was only a highway=bus_stop node, this is often now
> dual tagged with public_transport=platform as well (which is correct).
>
> In places where there was only a highway=platform way/area, this is often
> now dual tagged with public_transport=platform was well (correct too).
>
> But in places that have both a highway=platform and a highway=bus_stop,
> dual tagging both with public_transport=platform is wrong. The two should
> be merged into only a single way/area with public_transport=platform. The
> problem then is that you can't really dual tag that anymore, because the
> highway=platform and highway=bus_stop tags are in direct conflict and can't
> be tagged on the same object.
>
> And because the lack of rendering in osm carto, many people are not going
> to use PTv2 properly in this case, because they can't dual tag it so that
> it will properly show up on the map.
>
> The lack of rendering support for public_transport=platform *as a
> replacement for highway=bus_stop and similar tags* is what prevents
> widespread adaption of PTv2 and deprecation of the old tagging scheme.
>
> Implementing public_transport=platform rendering purely as a 1:1
> replacement of highway/railway=platform, without properly supporting it as
> a replacement of bus_stop, tram_stop, and so on is not going to fix that
> issue.
>
> > -Original Message-
> > From: marc marc 
> > Sent: Thursday, 21 June 2018 02:53
> > To: tagging@openstreetmap.org
> > Subject: Re: [Tagging] public_transport=platform rendering on osm-
> > carto
> >
> > Le 20. 06. 18 à 17:44, Jo a écrit :
> > > Actually I have started to remove public_transport=platform from
> > WAYS
> > > with highway=platform and railway=platform. As far as I am
> > concerned
> > > public_transport=platform goes on NODES
> >
> > sorry I didn't understand why (or maybe yes I prefer to not
> > understand) Zverik's propal that you clone to request that
> > public_transport=platform as way should be downgraded to a node-
> > only HAS FAILED !
> > So if another mapper extend the node to better match the geometry
> > of the plateform, why are you revert it ?
> > yes wiki is ambigous. but for almost (?) all objects the extend
> > from a node into a more precise geometry has always been considered
> > an improvement, not a mistkae that need to be fixed.
> > So the next contributor will probably add the PTv2 tags you deleted.
> >
> > > Removing those tags from ways comes from the objection of some
> > people
> > > that there would be both a way and a platform with the
> > > public_transport=platform tag.
> >
> > I remember this talk about that on tranport (french-speaking
> > transit) mailing when it became apparent that duplicate objects
> > were so common in France that they affected stats at a regional
> > scale.
> > This resulted in a collective work to add missing PTv2 tags, many
> > contributors spent many hours for that and fix a lot of mistake.
> > Currently the region of french capital is nearly 100% PTv2 and at
> > the country scale in france, there is almost no highway=plateform
> > tag left that does not also have its PTv2 equivalent.
> >
> > Of course one stop in one direction should have :
> > - only one plateform per "passenger waiting area" (including all
> > variant public_transport=platform highway=platform and
> > railway=platform) and/or
> > - one stop_position
> >
> > having one "passenger waiting area" mapped as a node + as a way + a
> > MP like I already see, with tags randomly distributed or duplicated
> > between these osm objects that represent the same thing, it is a
> > mess
> >
> > and PTv1 tag should of course be put only on one of the same objets.
> >

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

2018-06-20 Thread Jo
If v2 of the 'new' scheme means that we have to create 2 objects for each
and every bus stop and add both of those to the route relations and
duplicate details across them, then v2 has failed.

We should have exactly 1 object that represents the bus stop. A node next
to the way and only add that node to the route relations.

if there is an actual platform, we can draw a way or an area and tag it
highway=platform/railway=platform. These should not be added to the route
relations.

Neither should the stop_position nodes be added to the route relations, nor
should they get details like name, ref, etc.

So 1 node to represent the bus or tram stops, next to the way on either
side and only add details to those and only add these to the route
relations.

These nodes can get the public_transport=platform tags.

if we can start doing it that way, we will get a way of mapping public
transport that is easy to understand for everyone. If we don't the wiki
will remain murky, unclear and ambiguous.

I rest my case.

Polyglot

Op wo 20 jun. 2018 om 18:53 schreef marc marc :

> Le 20. 06. 18 à 17:44, Jo a écrit :
> > Actually I have started to remove public_transport=platform from WAYS
> > with highway=platform and railway=platform. As far as I am concerned
> > public_transport=platform goes on NODES
>
> sorry I didn't understand why (or maybe yes I prefer to not understand)
> Zverik's propal that you clone to request that public_transport=platform
> as way should be downgraded to a node-only HAS FAILED !
> So if another mapper extend the node to better match the geometry
> of the plateform, why are you revert it ?
> yes wiki is ambigous. but for almost (?) all objects the extend
> from a node into a more precise geometry has always been considered
> an improvement, not a mistkae that need to be fixed.
> So the next contributor will probably add the PTv2 tags you deleted.
>
> > Removing those tags from ways comes from the objection of some people
> > that there would be both a way and a platform with the
> > public_transport=platform tag.
>
> I remember this talk about that on tranport (french-speaking transit)
> mailing when it became apparent that duplicate objects were so common
> in France that they affected stats at a regional scale.
> This resulted in a collective work to add missing PTv2 tags,
> many contributors spent many hours for that and fix a lot of mistake.
> Currently the region of french capital is nearly 100% PTv2 and at the
> country scale in france, there is almost no highway=plateform tag left
> that does not also have its PTv2 equivalent.
>
> Of course one stop in one direction should have :
> - only one plateform per "passenger waiting area" (including all variant
> public_transport=platform highway=platform and railway=platform)
> and/or
> - one stop_position
>
> having one "passenger waiting area" mapped as a node + as a way + a MP
> like I already see, with tags randomly distributed or duplicated between
> these osm objects that represent the same thing, it is a mess
>
> and PTv1 tag should of course be put only on one of the same objets.
> If not, you make duplicate objet for the same feature... like currently.
>
> > In other words, the rendering of *=platform on WAYS is just fine as it
> is.
>
> of course that it is the continuation of Zverik's failed proposal.
> but check current pratice :
> the supremacy of public_transport=platform over highway=platform
> is even clearer if we take into account the duplicate tag
> 900k for public_transport=platform without (highway=platform or
> railway=platform)
> 84k highway=platform + public_transport=platform
> only 9k highway=platform without public_transport=platform
> the community has already twice rejected this unintelligible wish to
> have a PTv2custom with different rules totally useless depending
> on the transport mode.
> PTv2 consists precisely in making things more HOMOGENEOUS.
> So please reconsider your modifications and take into account that
> highway=plateform and public_tramsport=plateform are 2 tags for the same
> concept (a passenger waiting area for a public transport), even if the
> render support only the oldest and less common schema for *=platform
>
> Regards,
> Marc
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2018-06-20 Thread Jo
Actually I have started to remove public_transport=platform from WAYS with
highway=platform and railway=platform. As far as I am concerned
public_transport=platform goes on NODES next to the ways in combination
with highway=bus_stop or railway=tram_stop.

Removing those tags from ways comes from the objection of some people that
there would be both a way and a platform with the public_transport=platform
tag.

In other words, the rendering of *=platform on WAYS is just fine as it is.

Polyglot


Op wo 20 jun. 2018 om 17:02 schreef Daniel Koć :

> W dniu 19.06.2018 o 17:40, osm.tagg...@thorsten.engler.id.au pisze:
> > But I do not think that it is reasonable to add rendering for it, and at
> the same moment drop rendering for highway=platform, railway=platform,
> highway=bus_stop, railway=tram_stop and everything else that
> public_transport=platform is meant to replace.
> >
> > This absolutely needs to be a two step process. Add rendering for
> public_transport=platform first, then let people work on migrating existing
> data. At some point in the future it might then become possible to drop
> rendering for existing tags.
>
> I want to make just one step now - replace *=platform with
> public_transport=platform. Next steps might be very different and i
> don't see them clearly now. It might even need PTv3 - I don't know, so I
> won't touch it.
>
> We could of course migrate by adding new type and removing old ones
> after some time and I would do it. However on osm-carto we have a strong
> opposition to rendering multiple similar tags (fear of fragmentation),
> so I prefer to start with announcing the planned change and then make
> the switch in rendering. It's just a different way of migration and if
> it won't create (unnecessary in this case) tension and makes the whole
> thing more probable to happen, I vote for it.
>
> --
> "My method is uncertain/ It's a mess but it's working" [F. Apple]
>
>
>
> ___
> 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

2018-06-19 Thread Jo
highway=platform is a tag that goes on a way, just like railway=platform.

public_transport=platform can go on both ways and nodes. If on a node next
to the highway/railway, public_transport=platform/bus=yes is the equivalent
of highway=bus_stop and public_transport=platform/tram=yes is the
equivalent of railway=tram_stop

There are also public_transport=stop_position combined with higway=bus_stop
as nodes of highways. I think we should convert those to
public_transport=platform/bus=yes/highway=bus_stop
positioned next to the highways.

Thanks for looking into this. I had already stopped caring about it and
resorted to simply double tagging everything. Ilya Zverev even proposed to
simply drop the "new" public_transport scheme and revert back to
highway=bus_stop/railway=tram_stop in large part because it's not getting
rendered. At some point I thought this whole scheme was a good idea, but it
resulted in wiki pages saying that every stop supposedly needs to be mapped
twice (once on the highway and once next to it) and added to all route
relations twice, which to me seems absurd, but OK, I've given up on caring
about that as well.

Polyglot.

Op di 19 jun. 2018 om 17:14 schreef marc marc :

> Le 19. 06. 18 à 16:30, Daniel Koć a écrit :
> > I realized that highway=platform is not only marked on wiki as much less
> > popular, but is also really 10 times less popular in the database.
>
> and for 93 906 highway=platform, 84 031 already have
> public_transport=platform
> https://taginfo.openstreetmap.org/tags/highway=platform#combinations
>
> this is a subject where it is very difficult to progress,
> so I advise to do this in 2 steps:
> check and add missing public_transport=plateform on highway=platform
> and for osm-carto add a rendering of public_transport=plateform
> from what I see, the only use of this tag is to have the missing
> rendering on PTv2
> During this period it will be possible for everybody to express whether
> they see a difference between highway=plateform and
> public_transport=plateform.
>
> Previous experiences have shown that it is better not to talk right away
> about depreciating a tag until you have a "complete" alternative
>
> Regards,
> Marc
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] `amenity=shelter` implies `building=yes`?

2018-06-18 Thread Jo
shelter=yes on a highway=bus_stop NODE indicates there is a shelter nearby,
but says nothing about where it is exactly nor its size.

amenity=shelter
shelter_type=public_transport

on a CLOSEDWAY

indicates where the shelter is. height is not super important. I guess most
are about 2.3m high. If it is considered important I'll go out and measure
one and start tagging that on them. But that still doesn't make them
buildings. They are more like containers with glass wall panels and a metal
roof on a slab of concrete. Relatively easy to move and relatively small in
size.

Polyglot

Op ma 18 jun. 2018 om 15:28 schreef Bryan Housel :

> There are also picnic shelters .. here they can have no walls just a roof
> to shelter from the heat of the sun or the occasional bit of rain.
> e.g.
> https://www.riversideca.gov/park_rec/sites/riversideca.gov.park_rec/files/pictures/Picnic%20Shelter%20Hunter%20hobby.JPG
>
>
> I would tag that as:
>
> amenity=shelter
> building=roof( <— this tag is really the point of the thread)
>
>
> The following three are no buildings from my point of view because they
> have one wall only. Either the two other walls do not fully stretch from
> the ground to the roof or the shelter itself can be removed easily.
> https://www.mapillary.com/app/?lat=49.08680549357706=9.078079866007897=17=90pd5WuYg8zOk_L8dxLFFQ=photohttps://www.mapillary.com/app/?lat=49.08985722389377=9.07931005221235=17=oXQHKqb3Lc3Ae9IXj-5PHw=photohttps://www.mapillary.com/app/?lat=49.10616167487336=9.121348618135698=17=8xUGL_VKp45sOfd9VW7dUw=photo
>
> I would not use `amenity=shelter` at all and instead tag those as
> https://wiki.openstreetmap.org/wiki/Tag:highway=bus_stop
>
> highway=bus_stop
> public_transport=platform
> bus=yes
> shelter=yes
> bench=yes
>
>
> There is building=roof but I would not use it for such shelters. They
> are not treated as buildings by the cadastre, why should I do? (If they
> are larger and have no walls, they
>
> Anything that should show up on a 3D map needs a `building` tag and maybe
> a `height`.
>
> I think that nobody of us knows the whole world and that's why I ask you
> not to decide on the default values of the whole world. If local mappers
> think that a shelter is a building, they will tag it as such. If they
> think that it does not qualify to be a building, they will not add the tag.
>
> In iD, the things we provide as presets, and how we render those things on
> the screen influence how people map.
>
> It sounds like from the discussion that we should not assume that shelters
> are buildings, and instead provide a field so that mappers can decide.
> Once we provide this field, we can expect a lot of people to use it.  (I’m
> trying to engage the tagging list a lot more so that people feel consulted
> when I change things in iD.)
>
> Thanks, Bryan
>
>
>
> ___
> 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] `amenity=shelter` implies `building=yes`?

2018-06-17 Thread Jo
most have 4 glass walls. The smaller type in the other picture is more
recent. Not much shelter from the elements in those. I guess that one could
be building=roof, but it wouldn't be much of a shelter without any roof at
all, so I took that as implied.

I have not seen many bus shelters mapped as buildings.

Jo

Op zo 17 jun. 2018 om 08:43 schreef Shawn K. Quinn :

> On 06/16/2018 11:45 PM, Bryan Housel wrote:
> > Does `amenity=shelter` imply `building=yes`?
>
> If this is for bus stop/transit shelters, it would imply building=roof
> at minimum. The shelters here usually have three walls (sometimes only
> one wall) with the fourth side being open to the street, plus a canopy
> to protect from rain.
>
> --
> Shawn K. Quinn 
> http://www.rantroulette.com
> http://www.skqrecordquest.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] `amenity=shelter` implies `building=yes`?

2018-06-17 Thread Jo
I tag bus stop shelters with amenity=shelter,
shelter_type=public_transport. In Belgium they are constructions with glass
'walls' and a metal roof. I don't consider them as buildings though.

https://www.mapillary.com/app/user/polyglotopenstreetmap?lat=50.8884666=4.7537767=17=6BcoR8U--jKnsHJUsDTk4g=photo

some are smaller:

https://www.mapillary.com/app/user/polyglotopenstreetmap?lat=50.8872816667=4.7474284=17=1BF1bW6NzDMmG_wCU7v4Tg=photo=0.514565120648143=0.41978226626934106=0

I do use JOSM's buldings-tools plugin to draw them. Really convenient to
draw rectangular closed ways with the right tags on them, straight away.

Polyglot

Op zo 17 jun. 2018 om 06:46 schreef Bryan Housel :

> Does `amenity=shelter` imply `building=yes`?
>
> The osm wiki page does not suggest `building=*` as a “tag to use in
> combination”
> https://wiki.openstreetmap.org/wiki/Tag:amenity=shelter
>
> But most other features which are closed-way structures need the
> `building=*` tag.  I know it’s a tag used by 3D mapping.  It seems like for
> consistency, we should add an explicit `building=*` tag.
>
> Asking for https://github.com/openstreetmap/iD/issues/5084
>
> thanks Bryan
>
> ___
> 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] I can't support transit:lanes

2018-06-11 Thread Jo
Name should indeed be changed, but I'd go for lanes:transition, so it
groups with the other lanes related tags. Not sure if that is a good type
for the relation though.

There is no need to bother the user, in case there is an adjacent way with
this tag. Then it's obvious which part of the split off way should either
remain in the relation or keep the tag.

In case there is no adjacent way with that tag, or the relation contains 2
ways which don't connect, a validation error should be shown.

Polyglot

Op ma 11 jun. 2018 om 08:07 schreef Mateusz Konieczny <
matkoni...@tutanota.com>:

> For JOSM see https://josm.openstreetmap.de/ticket/11054
>
> 11. Jun 2018 06:42 by bhou...@gmail.com:
>
> I’m not going to add a special rule in iD to warn people if they are
> splitting a way with a lane transition tag.  I don’t want to speak for the
> JOSM devs, but I doubt they would implement something like this either.
>
> ___
> 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] new role for route relations: reverse

2018-05-29 Thread Jo
2018-05-29 11:05 GMT+02:00 Andrew Davidson :

> On 29/05/18 14:04, Jo wrote:
>
>>
>> We're talking about PT v2.
>>
>>
> In which case I don't understand why we want to create a new role. If you
> are using PTv2 then you will have the same way listed twice at the point
> that the route turns around. If you add more of the stops to your route it
> will be more obvious to other mappers that you haven't made a mistake. I'd
> suggest at least putting in the ones at the far ends of the "detours".


The odd thing about this route is that it serves 1 stop at the start of
this cul-de-sac then continues and turns around. There is no other stop at
the end, where it makes the maneuver.

Anyway, it's not crucial to have this role. For making the route continuous
it's indeed enough to repeat the ways. So maybe I better drop it.

But if we're going to a add a role for hail_and_ride and editors need to be
adapted to accomodate this, we could include this role as well, while we're
at it.

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


Re: [Tagging] new role for route relations: reverse

2018-05-28 Thread Jo
It's not about the 'gear'. It's about the vehicle needing to do something
that, as far as I'm concerned, is totally unexpected on a bus route. If
they put the gear in neutral and had some slaves/volunteers there that
pushed the bus backwards (and a supervisor checking they don't run anybody
over), the situation would be exactly the same (OK, that would be even more
unexpected).

Can we make do without such a role? Sure we can. I wanted to be explicit,
rather than implicit.

It's not crucial, maybe I should just drop proposing it. Good thing I
didn't waste time describing it on the wiki then.

Jo

2018-05-29 6:04 GMT+02:00 Jo :

>
>
> 2018-05-29 1:09 GMT+02:00 Graeme Fitzpatrick :
>
>> Could you fool the routers / system by inserting an imaginary
>> mini-roundabout at the end of the cul-de-sac?
>>
>> That way the router would think that the bus drives in, goes round the
>> roundabout, then drives out again.
>>
>> Include a note that the roundabout doesn't actually exist, but is only
>> shown for this reason, so that other mappers don't then keep deleting it!
>>
>
> I really fail to see why would have to add data that doesn't exist,
> instead of describing exactly what is happening.
>
> We're talking abtout PT v2.
>
> This is the route relation:  https://www.openstreetmap.org/relation/
> 7620346
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] new role for route relations: reverse

2018-05-28 Thread Jo
2018-05-29 1:09 GMT+02:00 Graeme Fitzpatrick :

> Could you fool the routers / system by inserting an imaginary
> mini-roundabout at the end of the cul-de-sac?
>
> That way the router would think that the bus drives in, goes round the
> roundabout, then drives out again.
>
> Include a note that the roundabout doesn't actually exist, but is only
> shown for this reason, so that other mappers don't then keep deleting it!
>

I really fail to see why would have to add data that doesn't exist, instead
of describing exactly what is happening.

We're talking abtout PT v2.

This is the route relation:  https://www.openstreetmap.org/relation/7620346
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] new role for route relations: reverse

2018-05-28 Thread Jo
Hi,

A few days ago I helped Paul Allen with mapping some bus routes. During one
of these itineraries, the bus has to do something totally counterintuitive,
twice!
It has to back up in reverse to get out of a cul-de-sac. The obvious way to
solve this to me is to double the way it starts reversing on, then the side
street it backs in to, then that side street again and then the sequence of
streets it followed into that pickle in reverse order.

For the streets where the bus backs up in reverse, I would like to add a
role=reverse. This should not conflict with the recently proposed
role hail-and-ride, as I can't imagine one would be able to board the
vehicle while it's backing up. It will always be on a way that is in the
relation twice, so hail-and-ride can still be set on those ways where the
bus drives forward.

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


Re: [Tagging] roundtrip

2018-05-28 Thread Jo
I only saw the discussion in this thread, came to the conclusion I (and
probably many other Dutch and German speakers) had interpreted the meaning
completely wrong.

The tag is indeed meaningless, as it stands. Especially for public
transport, where it really doesn't matter. We're describing itineraries.
For hiking/cycling it's a misnomer. So it would be good to phase it out.

What I'm trying to accomplish, while we're doing that is to not only
replace it with circular_route, to indicate intent, but to also add a tag
that validators can use to perform validation.

Jo

2018-05-28 9:54 GMT+02:00 Volker Schmidt <vosc...@gmail.com>:

> Have you seen the discussion on the roundtrip tag [1]?
> It looks as if there are two different roundtrip concepts in use:
> For hiking or cycling routes it means that the route you follow brings you
> back to the starting point with the outwards route and the return route
> (mostly) different.
> in a traffic service round trip is often used to indicate a service "there
> and back"
> "roundtrip=yes|no" is an unfortunate choice of key as it has wo meanings,
> mainly ccording to which side of the Atlantic Ocean you are. but its in use
> about 25k times.
> It might have been better to have something like "loop=yes|no" for hiking
> and cycling routes.
> For bus|underground|tram lines it might have been better to use something
> like "geometry=linear|circular|..." for transportation routes.
>
> [1] https://wiki.openstreetmap.org/wiki/Talk:Key:roundtrip
>
> On 28 May 2018 at 08:52, Jo <winfi...@gmail.com> wrote:
>
>> From what I gathered during this discussion, roundtrip is mostly
>> understood and used wrongly by mappers.
>>
>> It's also not something about the route, but rather about a passenger who
>> buys a ticket to come back the same way the same day/weekend and paying the
>> return fare on the same ticket (aller/retour - heen- en terug).
>>
>> So I went and downloaded all objects tagged with roundtrip. The one I
>> changed needed major clean up in its members anyway.
>>
>> So how do we get from a meaningless tag (roundtrip) to something that
>> actually has meaning for itineraries?
>>
>> I think that on the one hand we need a tag to describe what the user can
>> expect (get back to approximate initial position) and on the other hand it
>> would be nice (for validation purposes) to know if the ways in the relation
>> are supposed to form a closed loop.
>>
>> hence:
>> circular_route=yes
>> closed_loop=no
>>
>> for that particular bus route.
>>
>> Polyglot
>>
>> 2018-05-28 7:47 GMT+02:00 <osm.tagg...@thorsten.engler.id.au>:
>>
>>> The real question, which as far as I can tell you haven’t answered, is:
>>> Does that same vehicle, after completing its route, start at the beginning
>>> of the same route again?
>>>
>>>
>>>
>>> Based on your description, the route as mapped is A1->B->C->D->E->A2.
>>>
>>>
>>>
>>> Can I get on at E, stay on the vehicle, and get off at B? (In which case
>>> I would expect that after finishing at A2, the vehicle goes to A1, and you
>>> can remain on board during that time. A2 may be (but doesn’t have to) an
>>> “exit only” and A1 and “entry only” stop).
>>>
>>>
>>>
>>> If yes, then it is roundtrip=yes. And you shouldn’t just remove an
>>> existing tag that actually applies.
>>>
>>> If no, then the roundtrip=yes is wrong and should be removed.
>>>
>>>
>>>
>>> *From:* Jo <winfi...@gmail.com>
>>> *Sent:* Monday, 28 May 2018 15:13
>>> *To:* Tag discussion, strategy and related tools <
>>> tagging@openstreetmap.org>
>>> *Subject:* Re: [Tagging] roundtrip
>>>
>>>
>>>
>>> An example of a (bus) route that goes out and comes back to the same
>>> location. It's not circle shaped at all, but that shouldn't matter for
>>> circular route.
>>>
>>>
>>>
>>> I removed roundtrip=yes and replaced it with
>>>
>>>
>>>
>>> circular_route=yes
>>>
>>> closed_loop=no
>>>
>>>
>>>
>>> If the last way wouldn't be in there, closed_loop would be yes. But the
>>> first and the last bus stops are not exactly opposite one another.
>>>
>>>
>>>
>>> Jo
>>>
>>>
>>>
>>>
>>>
>>> 2018-05-27 6:22 GMT+02:00 Paul Johnson <ba...@ursamundi.or

Re: [Tagging] roundtrip

2018-05-28 Thread Jo
>From what I gathered during this discussion, roundtrip is mostly understood
and used wrongly by mappers.

It's also not something about the route, but rather about a passenger who
buys a ticket to come back the same way the same day/weekend and paying the
return fare on the same ticket (aller/retour - heen- en terug).

So I went and downloaded all objects tagged with roundtrip. The one I
changed needed major clean up in its members anyway.

So how do we get from a meaningless tag (roundtrip) to something that
actually has meaning for itineraries?

I think that on the one hand we need a tag to describe what the user can
expect (get back to approximate initial position) and on the other hand it
would be nice (for validation purposes) to know if the ways in the relation
are supposed to form a closed loop.

hence:
circular_route=yes
closed_loop=no

for that particular bus route.

Polyglot

2018-05-28 7:47 GMT+02:00 <osm.tagg...@thorsten.engler.id.au>:

> The real question, which as far as I can tell you haven’t answered, is:
> Does that same vehicle, after completing its route, start at the beginning
> of the same route again?
>
>
>
> Based on your description, the route as mapped is A1->B->C->D->E->A2.
>
>
>
> Can I get on at E, stay on the vehicle, and get off at B? (In which case I
> would expect that after finishing at A2, the vehicle goes to A1, and you
> can remain on board during that time. A2 may be (but doesn’t have to) an
> “exit only” and A1 and “entry only” stop).
>
>
>
> If yes, then it is roundtrip=yes. And you shouldn’t just remove an
> existing tag that actually applies.
>
> If no, then the roundtrip=yes is wrong and should be removed.
>
>
>
> *From:* Jo <winfi...@gmail.com>
> *Sent:* Monday, 28 May 2018 15:13
> *To:* Tag discussion, strategy and related tools <
> tagging@openstreetmap.org>
> *Subject:* Re: [Tagging] roundtrip
>
>
>
> An example of a (bus) route that goes out and comes back to the same
> location. It's not circle shaped at all, but that shouldn't matter for
> circular route.
>
>
>
> I removed roundtrip=yes and replaced it with
>
>
>
> circular_route=yes
>
> closed_loop=no
>
>
>
> If the last way wouldn't be in there, closed_loop would be yes. But the
> first and the last bus stops are not exactly opposite one another.
>
>
>
> Jo
>
>
>
>
>
> 2018-05-27 6:22 GMT+02:00 Paul Johnson <ba...@ursamundi.org>:
>
> On Fri, May 25, 2018 at 5:41 AM, Peter Elderson <pelder...@gmail.com>
> wrote:
>
> I wish you a happy trip on that bus, hope it has toilets and a tolerable
> coffee machine
>
>
>
> Oh, you sweet, summer child.  Someone's never tried to take a suburban
> route in the US, even in a "transit oriented" American city...
>
>
> ___
> 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] roundtrip

2018-05-27 Thread Jo
An example of a (bus) route that goes out and comes back to the same
location. It's not circle shaped at all, but that shouldn't matter for
circular route.

I removed roundtrip=yes and replaced it with

circular_route=yes
closed_loop=no

If the last way wouldn't be in there, closed_loop would be yes. But the
first and the last bus stops are not exactly opposite one another.

Jo


2018-05-27 6:22 GMT+02:00 Paul Johnson <ba...@ursamundi.org>:

> On Fri, May 25, 2018 at 5:41 AM, Peter Elderson <pelder...@gmail.com>
> wrote:
>
>> I wish you a happy trip on that bus, hope it has toilets and a tolerable
>> coffee machine
>>
>
> Oh, you sweet, summer child.  Someone's never tried to take a suburban
> route in the US, even in a "transit oriented" American city...
>
> ___
> 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] roundtrip

2018-05-26 Thread Jo
For validation purposes it would be interesting to know if the ways in the
route relation are supposed to form a closed loop. Can we adopt
closed_loop=yes for that use case?

Polyglot

2018-05-26 12:10 GMT+02:00 Peter Elderson :

> I would like to wrap this up, without a formal proposal process, if there
> is no fundamental objection.
> Afterwards, I will announce it in the Dutch community and arrange the
> re-tagging of existing usage.
>
> I suggest:
>
> * Update the wiki page for key: roundtrip, to reflect the correct meaning,
> and advize to use circular_route=yes or route:circular=yes (2Bdecided).
> Whether or not the redefined key:roundtrip is still useful or should be
> deprecated, can be decided later. It does not matter to me, at this point.
>
> * Add a page for the new key:circular_route=yes|no or
> route:circular=yes|no, to indicate that a route is to be regarded as
> circular/linear (no matter if it's a closed route on the map or not).
>
> If other route variants are foreseen, maybe route:circular=yes|no is
> better?
>
> Details about context and use cases can be added and modified through the
> talk-pages.
>
> Allright?
>
> 2018-05-25 23:46 GMT+02:00 Warin <61sundow...@gmail.com>:
>
>> On 25/05/18 21:31, Peter Elderson wrote:
>>
>> It's an example. But we are not alone...
>>
>>
>> Same in Sydney Australia - billed on entry and exit points .. not on how
>> long you have been inside the  transport system system.
>> Some 'homeless' use it as a warm dry resting place, doing long round
>> trips.
>>
>>
>> 2018-05-25 12:33 GMT+02:00 Martin Koppenhoefer :
>>
>>> 2018-05-25 12:29 GMT+02:00 Peter Elderson :
>>>
 How would that be applicable in Nederland, where PT uses one type of
 chipcard for all voyages and payment is based on distance travelled between
 check-in and check-out, no matter the route or vehicle?

>>>
>>>
>>> isn't this offtopic? Why would we care if the Dutch PT tariffing can
>>> deal with roundtrips or not?
>>>
>>> Cheers,
>>> Martin
>>>
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>>>
>>
>>
>> --
>> Vr gr Peter Elderson
>>
>>
>> ___
>> Tagging mailing 
>> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>>
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>>
>
>
> --
> Vr gr Peter Elderson
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] roundtrip

2018-05-25 Thread Jo
I don't see a problem with adding tags that enable validation to be
performed, even if it means some redundancy in the data. But I may have
misinterpreted the roundtrip tag myself.

Jo

2018-05-25 11:52 GMT+02:00 Peter Elderson <pelder...@gmail.com>:

> Isn't that should-be tagging for the validator? I don't know if that's
> less frowned-upon than tagging for the renderer...
> Besides, if you derive the tag from your tagging tool, couldn't the
> validator do that directly?
>
> 2018-05-25 11:15 GMT+02:00 Jo <winfi...@gmail.com>:
>
>> I tend to use roundtrip=yes when (after fixing) a route relation gets
>> this double way icon next to the ways, instead of a single vertical line
>> (JOSM only ofc).
>>
>> If we all start using it that way, we could create a validator rule for
>> checking the relation is still 'all right'.
>>
>> Polyglot
>>
>> 2018-05-25 11:10 GMT+02:00 Johnparis <ok...@johnfreed.com>:
>>
>>> Interesting.
>>>
>>> Similarly, a route that is not closed can be a roundtrip. The start and
>>> end points might be several meters apart, even on different roads, yet
>>> serve the same destination. There are a few (very few) examples I have
>>> found in the Paris area. Here's one. It's not marked roundtrip=yes but
>>> probably should be:
>>>
>>> https://www.openstreetmap.org/relation/8140184
>>>
>>> I agree that this tag seems to be of very limited usefulness, though I
>>> confess to having used it on occasion.
>>>
>>>
>>> On Fri, May 25, 2018 at 10:55 AM, Warin <61sundow...@gmail.com> wrote:
>>>
>>>> On 25/05/18 15:48, Peter Elderson wrote:
>>>>
>>>> What is the use of the key:roundtrip?
>>>> Explanations just say
>>>> roundtrip <https://wiki.openstreetmap.org/wiki/Key:roundtrip>=yes/no 
>>>> (optional)
>>>> Use roundtrip=no to indicate that a route goes from A to B. Use
>>>> roundtrip=yes to indicate that the start and finish of the route are at the
>>>> same location (circular route). It seems rather pointless to tag an
>>>> obvious a-b route with roundtrip=no, or an abvious roundtrip with
>>>> roundtrip=yes.
>>>> Why would you tag an a-b route as roundtrip=yes, or a closed route as
>>>> roundtrip=no?
>>>>
>>>>
>>>> A route that is 'closed' can be a non round trip.
>>>> For example the bus only does one circuit then goes on to another route
>>>> elsewhere. This can be done to provide services to both that route and to
>>>> other parts of the community with other routes.
>>>> There may not be enough demand for a continuous circuit to be viable.
>>>>
>>>> ___
>>>> 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
>>
>>
>
>
> --
> Vr gr Peter Elderson
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] roundtrip

2018-05-25 Thread Jo
Paul,

Let me know when you would have time for a hangout. I'd like to have a look
at that route! Preferably with somebody who actually knows how the bus
follows it.

But a line that does A->B, then B->A is not a roundtrip, and it would take
2 route relations to describe the itineraries + a route_master to describe
the line.

Jo

2018-05-25 12:51 GMT+02:00 Paul Allen <pla16...@gmail.com>:

>
>
> On Fri, May 25, 2018 at 11:20 AM, Peter Elderson <pelder...@gmail.com>
> wrote:
>
>> In that case it is a service-thing rather than a route-thing. Is it
>> generally used like that?
>> The wiki just mentions the co-location of start/endpoint of the route.
>>
>> I'm going by what I've encountered in various towns and cities.
>
> I've seen many routes where the bus goes from A->B, passengers disembark
> at B,
> new passengers board at B and the bus then goes from B->A.  It's not a
> round trip.
> Even if you buy a return ticket or have an unlimited use ticket, you still
> have to get
> off at B.  Often there is a 5 or 10 minute (or longer) layover at B while
> the driver
> has a piss or a cup of coffee or a smoke (or all three at once, perhaps).
>
> I've also seen routes where it truly is a round trip (and most of those
> were also
> circulars).  With an unlimited ticket you could stay on the bus all day.
> I met one
> guy who did because in winter it cost him too much to heat his house, so
> there
> he was on the bus with a packed lunch, several cans of beer (illegal) and
> a happy
> grin.
>
> There is also a route I've yet to map, and am struggling to figure out how
> to
> do it.  One of the things I can handle is still pertinent: it goes from
> the bus station
> (A) like this: A->B->C->D->A->B->P->A->Z->A->B [out of service] -> A.  Z
> is
> actually a roundabout, with no official stops between it and A, merely so
> the bus
> can enter A in one direction and come back in the other.  But it's a
> hail-and-ride
> service, so theoretically it's possible to get off or on at Z.  Over the
> entire route
> it's not a round trip even though it visits some parts of the route more
> than once.
> Actually, I simplified a lot.  There are aspects of that route I can't
> figure out how
> to handle.
>
> --
> Paul
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] roundtrip

2018-05-25 Thread Jo
Ticket pricing shouldn't have anything to do with it. Here in Belgium, you
buy a ticket valid for a specific duration. As long as it didn't expire,
you can still board the vehicle.

OK, I'm not sure what would happen if you got onto a 'roundtrip' bus with a
ticket valid for 1 hour and you are still on it 3 hours later... Oh those
corner cases!

Jo

2018-05-25 12:32 GMT+02:00 <osm.tagg...@thorsten.engler.id.au>:

> Or to express it even more general:
>
>
>
> If you start at any stop, and remain on the vehicle, you will at some
> later point get back to the stop you started on.
>
>
>
> *From:* osm.tagg...@thorsten.engler.id.au <osm.tagging@thorsten.engler.
> id.au>
> *Sent:* Friday, 25 May 2018 20:23
> *To:* 'Tag discussion, strategy and related tools' <
> tagging@openstreetmap.org>
> *Subject:* Re: [Tagging] roundtrip
>
>
>
> I interpret roundtrip as “you can get from a stop to another stop that’s *
> *before** it in the list of stops by simply remaining in the vehicle”.
>
>
>
> You can have routes where the start and stop are the same location, but
> this is not true (as the vehicle always goes on to serve another route
> after arriving at the last stop).
>
>
>
> *From:* Peter Elderson <pelder...@gmail.com>
> *Sent:* Friday, 25 May 2018 15:48
> *To:* Tagging list OSM <tagging@openstreetmap.org>
> *Subject:* [Tagging] roundtrip
>
>
>
> What is the use of the key:roundtrip?
>
> Explanations just say
>
> roundtrip <https://wiki.openstreetmap.org/wiki/Key:roundtrip>=yes/no
>
> (optional) Use roundtrip=no to indicate that a route goes from A to B. Use
> roundtrip=yes to indicate that the start and finish of the route are at the
> same location (circular route).
>
> It seems rather pointless to tag an obvious a-b route with roundtrip=no,
> or an abvious roundtrip with roundtrip=yes.
>
> Why would you tag an a-b route as roundtrip=yes, or a closed route as
> roundtrip=no?
>
>
>
> The only use case I can imagine is when a roundtrip has one ore more
> access ways which are included in the route relation. But even then, what
> is the purpose?
>
>
>
> Allowing apps to select only "official" roundtrips? Is that a valid reason
> for tagging?
>
>
>
> --
>
> Peter Elderson
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] roundtrip

2018-05-25 Thread Jo
I tend to use roundtrip=yes when (after fixing) a route relation gets this
double way icon next to the ways, instead of a single vertical line (JOSM
only ofc).

If we all start using it that way, we could create a validator rule for
checking the relation is still 'all right'.

Polyglot

2018-05-25 11:10 GMT+02:00 Johnparis :

> Interesting.
>
> Similarly, a route that is not closed can be a roundtrip. The start and
> end points might be several meters apart, even on different roads, yet
> serve the same destination. There are a few (very few) examples I have
> found in the Paris area. Here's one. It's not marked roundtrip=yes but
> probably should be:
>
> https://www.openstreetmap.org/relation/8140184
>
> I agree that this tag seems to be of very limited usefulness, though I
> confess to having used it on occasion.
>
>
> On Fri, May 25, 2018 at 10:55 AM, Warin <61sundow...@gmail.com> wrote:
>
>> On 25/05/18 15:48, Peter Elderson wrote:
>>
>> What is the use of the key:roundtrip?
>> Explanations just say
>> roundtrip =yes/no 
>> (optional)
>> Use roundtrip=no to indicate that a route goes from A to B. Use
>> roundtrip=yes to indicate that the start and finish of the route are at the
>> same location (circular route). It seems rather pointless to tag an
>> obvious a-b route with roundtrip=no, or an abvious roundtrip with
>> roundtrip=yes.
>> Why would you tag an a-b route as roundtrip=yes, or a closed route as
>> roundtrip=no?
>>
>>
>> A route that is 'closed' can be a non round trip.
>> For example the bus only does one circuit then goes on to another route
>> elsewhere. This can be done to provide services to both that route and to
>> other parts of the community with other routes.
>> There may not be enough demand for a continuous circuit to be viable.
>>
>> ___
>> 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] Feature Proposal - RFC - Walkingbus_stop

2018-05-19 Thread Jo
obviously  Quack, quack

2018-05-19 22:15 GMT+02:00 Paul Allen :

> On Sat, May 19, 2018 at 9:06 PM, marc marc 
> wrote:
>
>>
>> node public_transport=plateform for the waiting area
>> +
>> relation type=route route=walking_bus
>> yes duck tagging... it is a PTv2 :)
>>
>
> So if it walks like a bus, looks like a bus and quacks like a bus then
> it's a duck?
>
> --
> Paul
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop

2018-05-19 Thread Jo
yes, that sounds fine.

2018-05-19 21:20 GMT+02:00 Martin Koppenhoefer <dieterdre...@gmail.com>:

>
>
> sent from a phone
>
> > On 19. May 2018, at 19:04, Jo <winfi...@gmail.com> wrote:
> >
> > OTOH mapping the routes as route=foot/hiking/walking also doesn't fit,
> as such route relations don't have the concept of 'stops' with a time table.
>
>
> route=walking_bus?
> that’s duck tagging, simple and concise, and is easy to understand for who
> knows the concept.
>
> Cheers,
> Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop

2018-05-19 Thread Jo
OTOH mapping the routes as route=foot/hiking/walking also doesn't fit, as
such route relations don't have the concept of 'stops' with a time table.

Polyglot

2018-05-19 18:44 GMT+02:00 Martin Koppenhoefer :

>
>
> sent from a phone
>
> > On 19. May 2018, at 16:56, marc marc  wrote:
> >
> > access limited to a certain audience ? some are, others are not.
>
>
> If it isn’t transportation for the general public I would not map it as
> public transport.
>
>
> 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] Feature Proposal - RFC - Walkingbus_stop

2018-05-18 Thread Jo
2018-05-18 17:11 GMT+02:00 Lorenzo Stucchi :

> Hi,
>
> After the discussion about that a walking school bus is not a  public
> transport, so the proposal is to change the tag to amenity, like for taxi
> rank.
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Walkingbus_stop
>
>
Do I understand correctly that you are not planning to map the itineraries?

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


Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop

2018-05-06 Thread Jo
Here in Belgium the public transport operator has school services that run
once or twice in each direction per school day. Anyone with a valid ticket
can take them though. So no exclusivity for school children.

There are other buses, organised by the schools themselves, which I also
wouldn't map. But those also don't have stops marked on the streets. They
simply go and pick up the children near their homes. They are mostly for
children with special needs though.

Jo

2018-05-06 23:28 GMT+02:00 Martin Koppenhoefer <dieterdre...@gmail.com>:

>
>
> 2018-05-06 11:21 GMT+02:00 Jo <winfi...@gmail.com>:
>
>> The foot tram routes definitely only if there are signs along the road,
>> indicating at what time the children are expected to be there.
>>
>> the walking_bus seems like a school bus, but without an actual vehicle.
>> There are stops with times that the 'bus' passes there and there is a fixed
>> itinerary. I suppose these are organised by a specific school, to get the
>> children on time to that school. For these I think it makes sense to map
>> them. Not sure if the public transport scheme is the best for it, but at
>> least it's what fits best.
>>
>
>
> I agree it is like a school bus without the bus, and school buses aren't
> public transport either.
>
> Cheers,
> Martin
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop

2018-05-06 Thread Jo
The foot tram routes definitely only if there are signs along the road,
indicating at what time the children are expected to be there.

the walking_bus seems like a school bus, but without an actual vehicle.
There are stops with times that the 'bus' passes there and there is a fixed
itinerary. I suppose these are organised by a specific school, to get the
children on time to that school. For these I think it makes sense to map
them. Not sure if the public transport scheme is the best for it, but at
least it's what fits best.

Polyglot

2018-05-06 10:53 GMT+02:00 Erkin Alp Güney :

> What about foot tram routes? Should they be mapped?
>
>
> 06-05-2018 11:51 tarihinde Selfish Seahorse yazdı:
> > Hi,
> >
> > Like Martin, I think the public transport scheme should not be used
> > here, because a walking bus is neither a form of transport nor is it
> > really public.
> >
> >
> > On 6 May 2018 at 09:45, Lorenzo Stucchi 
> wrote:
> >> Hi,
> >> I’m sorry for the error that I made using the old Public Transport
> scheme,
> >> so according to what was proposed before I correct the page proposing
> the
> >> tag: walikingbus=yes to be used with public_transport=platform like was
> now
> >> proposed in the page
> >>
> >> https://wiki.openstreetmap.org/wiki/Proposed_features/Walkingbus_stop
> >>
> >> Thanks and sorry again for my mistake
> >> Hi,
> >> LorenzoStucchi
> >>
> >> Date: Sun, 6 May 2018 12:28:09 +1000
> >> From: 
> >> To: "'Tag discussion, strategy and related tools'"
> >> 
> >> Subject: Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop
> >> Message-ID: <00ab01d3e4e1$e1575d50$a40617f0$@thorsten.engler.id.au>
> >> Content-Type: text/plain; charset="utf-8"
> >>
> >> Well, but based on your description, these are not planned routes in any
> >> way. They are purely transient emergent behaviour based on the fact
> that a
> >> lot of people want to move between these two points, and this is the
> obvious
> >> way to go.
> >>
> >> Take the people away, and the phenomenon disappears. This is not
> something
> >> that does not exist on its own.
> >>
> >> A bus route, a foot or hiking route, or a walking bus route on the other
> >> hand all exist even in the absence of people There are stops with signs,
> >> guiding signs, brochures showing the route... The route is planned and
> >> documented, and (at least till someone changes the planning) operate and
> >> exist even in the absence of people using them.
> >>
> >> The only thing that exist of what you describe is the environment that
> >> promotes this particular emergent behaviour, like the pedestrian zone
> sign,
> >> and these can and should obviously be mapped.
> >>
> >> -Original Message-
> >> From: Erkin Alp Güney 
> >> Sent: Sunday, 6 May 2018 00:59
> >> To: tagging@openstreetmap.org
> >> Subject: Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop
> >>
> >> Not really transient and some routes can be over 500m in length. For
> >> example, in Karşıyaka, more than 100 people/min/sq-m walks following
> >> Bahriye Üçok Boulevard (western sidewalk only) and Kemalpaşa Avenue
> >> (pedestrianised during the day and evening, pedestrian priority
> >> otherwise, marked by a pedestrian zone sign) between Karşıyaka
> >> Underground Car Parking and "Hergele Meydanı" (all comers' square).
> >>
> >>
> >> 05-05-2018 17:51 tarihinde osm.tagg...@thorsten.engler.id.au yazdı:
> >>
> >> If they are unmarked on the ground, are they documented somewhere?
> >>
> >> Or is it simply a case of "this is a common route a lot of people
> >>
> >> walk
> >>
> >> during certain times as there is a strong flow of people from A to
> >>
> >> B
> >>
> >> and this is the most commonly used route"? (In which case they
> >>
> >> aren't
> >>
> >> really something that exists as an entity of it's own and are only
> >>
> >> a
> >>
> >> transient event, though maybe a commonly reoccurring one.)
> >>
> >> In either case, it doesn't sound like a "walking bus" at all.
> >>
> >> -Original Message-
> >> From: Erkin Alp Güney 
> >> Sent: Sunday, 6 May 2018 00:09
> >> To: tagging@openstreetmap.org
> >> Subject: Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop
> >>
> >> No, foot tram routes are unmarked but you can easily join one by
> >> following the crowd. Normal foot routes have guiding signs.
> >>
> >>
> >> 05-05-2018 17:05 tarihinde osm.tagg...@thorsten.engler.id.au
> >>
> >> yazdı:
> >>
> >> Without a "driver", fixed "stops" and a defined schedule, that
> >>
> >> sounds more like what's currently already mapped using
> >>
> >> route=foot
> >>
> >> relations?
> >>
> >> -Original Message-
> >> From: Erkin Alp Güney 
> >> Sent: Saturday, 5 May 2018 23:28
> >> To: tagging@openstreetmap.org
> >> Subject: Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop
> >>
> >> We also have 

Re: [Tagging] Unifying large multi-location store chains

2018-05-04 Thread Jo
2018-05-03 23:27 GMT+02:00 Graeme Fitzpatrick :

> Hi
>
> I think I can see what you're getting at, but, as always, international
> usage is going to rear it's ugly head!
>
> We have Target & K-mart (not Big K-mart) in Australia, but over here
> Lowe's is a men's wear chain (Lowe's hardware was called Masters, but it
> crashed)
>
> There are also Woolworth's Supermarkets, but they are in no way related to
> the US or UK Woolworth chains.
>
> How do we get around problems like these?
>

brand:wikidata to the rescue!

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


Re: [Tagging] musical_instrument tag for publicly available musical instruments

2018-04-30 Thread Jo
- tag one of them as area, position the other as node inside the other

2018-04-30 11:00 GMT+02:00 Marc Gemis :

> On Sun, Apr 29, 2018 at 10:36 AM, José G Moya Y. 
> wrote:
> > I think this is a good idea, but, in the suggestion of Thorsten, I find
> > problematic the use of "access=" tag when instruments are in a bar.
> Imagine
> > a bar with a private piano is tagged as a point:
> >
> > amenity=bar
> > amenity=musical_instrument
> > musical_instrument=piano
> > access=private
>
> how can you add to amenities to 1 node without using e.g. a semi-colon ?
> so you have
>
> amenity=bar;musical_instrument
>
> Semi-colons in tags such as amenity and leisure (and other "main"
> tags) will often cause problems with the other tags. The reason is, as
> you pointed out, one does not know to which amenity or leisure the
> other tags applies.
>
> There are several solutions possible (depending on the case)
>
> - tag them as separate points (not a good idea here, as 1 is in the other)
> - tag one of them as area, position the other as node inside the other
> - another tagging scheme
>
> regards
>
> m.
>
> ___
> 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] tagging cycleable city-models focused on simulating road network

2018-04-23 Thread Jo
Things that are interesting to add as well are

fee / time period
bicycle rental
go cart rental
own bicycle allowed?

Polyglot

2018-04-23 11:13 GMT+02:00 Peter Elderson :

> The Dutch word is 'verkeerspark' (=traffic park).
>
> Some call them 'verkeerstuin'(traffic garden'), but I think that's just
> for promotion, it sounds more child-friendly in Dutch.
>
> There are variants for categories from toddlers to professional
> truckdrivers. I would use amenity=traffic_park and if needed another key
> for specification of type.
>
> 2018-04-23 9:56 GMT+02:00 Volker Schmidt :
>
>> I have struggled with this here in Italy.
>> Maybe we should try to promote amenity=traffic_park - see [1] - eve
>> though it only has three hits in taginfo so far.
>>
>> [1] https://en.wikipedia.org/wiki/Traffic_park
>>
>>
>>
>> On 23 April 2018 at 09:12, Mateusz Konieczny 
>> wrote:
>>
>>> On Sun, 22 Apr 2018 22:47:34 +0100
>>> Paul Allen  wrote:
>>>
>>> > It's almost as though the people who came up with those names were
>>> > given the instruction "Think of a name
>>> > that is completely unobvious for this thing and that nobody who saw
>>> > the name would realize what it actually
>>> > is."
>>>
>>> Direct translation from Polish
>>> ("miasteczko rowerowe" -> "bicycle town") is not good enough to justify
>>> neologism as a tag value.
>>>
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>>
>
>
> --
> Vr gr Peter Elderson
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] tagging cycleable city-models focused on simulating road network

2018-04-23 Thread Jo
Now you have 4. I've been wondering about this for a long time.

Polyglot

2018-04-23 9:56 GMT+02:00 Volker Schmidt :

> I have struggled with this here in Italy.
> Maybe we should try to promote amenity=traffic_park - see [1] - eve though
> it only has three hits in taginfo so far.
>
> [1] https://en.wikipedia.org/wiki/Traffic_park
>
>
>
> On 23 April 2018 at 09:12, Mateusz Konieczny  wrote:
>
>> On Sun, 22 Apr 2018 22:47:34 +0100
>> Paul Allen  wrote:
>>
>> > It's almost as though the people who came up with those names were
>> > given the instruction "Think of a name
>> > that is completely unobvious for this thing and that nobody who saw
>> > the name would realize what it actually
>> > is."
>>
>> Direct translation from Polish
>> ("miasteczko rowerowe" -> "bicycle town") is not good enough to justify
>> neologism as a tag value.
>>
>> ___
>> 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] How to map Outdoor Fitness Equipment

2018-04-20 Thread Jo
It is actually meant for adults. fitness_station seems like the best fit to
me.

Thanks

Jo

2018-04-21 1:24 GMT+02:00 Andrew Davidson <thesw...@gmail.com>:

> I had also thought fitness_station until I looked at the image and saw
> that we were talking about monkey bars.
>
> On Sat., 21 Apr. 2018, 09:10 nwastra, <nwas...@gmail.com> wrote:
>
>> leisure=fitness_station   https://wiki.openstreetmap.
>> org/wiki/Tag:leisure=fitness_station
>>
>> N
>>
>> On 21 Apr 2018, at 8:04 am, Jo <winfi...@gmail.com> wrote:
>>
>> A few days ago this was installed:
>>
>> https://www.mapillary.com/map/im/geAJ9RpsDDeDNQxqwpykBw
>>
>> Any suggestions on how to map it?
>>
>> Polyglot
>>
>> ___
>> 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] How to map Outdoor Fitness Equipment

2018-04-20 Thread Jo
A few days ago this was installed:

https://www.mapillary.com/map/im/geAJ9RpsDDeDNQxqwpykBw

Any suggestions on how to map it?

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


Re: [Tagging] Still RFC — Drop stop positions and platforms

2018-04-08 Thread Jo
2018-04-08 17:37 GMT+02:00 Philip Barnes :

> On Sun, 2018-04-08 at 15:52 +0100, Paul Allen wrote:
> > On Sun, Apr 8, 2018 at 2:57 PM, Philip Barnes 
> > wrote:
> > > Almost, Safle Bws is a bus stop. A bus station is Gorsaf Bws :)
> > >
> > > Phil (trigpoint)
> >
> > Let me look at my local bus station (well, what passes for one).
> >
> > Stands A, B, C, D and E.  Stand A consists of 4 bus shelters with at
> > least 3 different routes stopping at them,
> > In Welsh they are Safle A, Safle B, etc.
>
> That is referring to the stops (or stands) within the bus station. The
> overall area is Gorsaf Bws, same as as Railway Station (Gorsaf
> Reilffordd) and Police Station (Gorsaf Heddlu).
>
> It is very common to see the words Safle Bws painted on the road at Bus
> Stops.
>
> Phil (trigpoint)
>

This word stand sounds interesting. Could it also refer to the place where
people stand waiting at a regular bus stop next to a street? Or is it only
used in bus stations?

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


Re: [Tagging] no_u_turn restrictions for every entry/exit into a roundabout when the way is split because of physical separation?

2018-04-04 Thread Jo
That is absurd behaviour. Seems like somebody programmed a bot.

Polyglot

2018-04-05 1:49 GMT+02:00 Tod Fitch :

> Seems like tagging “noise” to me. I’d expect a router to use the
> roundabout itself because exiting, making a U turn and then re-entering the
> roundabout will be longer and thus slower. Since the no U turn relations
> are there to make routing work and a reasonable router won’t need them, I’d
> say they are “noise”. If I were to go in to fix something on that
> intersection, I’d probably remove the no U turn restriction(s). But I don’t
> think I’d go out of my way to find them.
>
> Cheers!
>
> On Apr 4, 2018, at 4:36 PM, osm.tagg...@thorsten.engler.id.au wrote:
>
> I’ve noticed that someone from the Microsoft Open Map team is very busy
> adding turn restrictions all over the place ( https://www.openstreetmap.
> org/user/shawat94/ ).
>
> In my local neighbourhood, I noticed that he added no_u_turn restrictions
> to all the nodes where a road into in/out of a roundabout is splitting
> (because of physical separation). Which basically amounts to 4 no_u_turn
> restrictions for every single roundabout.
>
> e.g. here:
> https://www.openstreetmap.org/changeset/57747093
> https://www.openstreetmap.org/changeset/57674063
>
> There is no actual no_u_turn sign in any of these locations, it’s just
> (mostly) physically a bad idea to attempt a u-turn here.
>
> Just a few weeks ago I discussed exactly this in #osm and the conclusion
> was that it was neither necessary nor desirable to do this.
>
> I made a comment about that to the first of the two changesets linked
> above, but haven’t gotten a reply.
>
> So, what is the general opinion about this here? Should these turn
> restrictions be created or not?
>
> Cheers,
> Thorsten
> ___
> 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] highway=stop and highway=give_way to traffic_sign=stop and traffic_sign=give_way

2018-04-02 Thread Jo
Those two tags go way back. Stop signs are important, so we've been mapping
them before the more general traffic_sign tags came along.

I'm using them as nodes on the highway, more to indicate the effect of
signage, than to indicate signage and traffic signs themselves.

2018-04-02 9:33 GMT+02:00 yo paseopor :

> Hi!
>
> I'm introducing myself. I'm yopaseopor . I'm from the Spanish and Catalan
> Communities of OSM. Also I have a particular interest because of the map:
> the traffic signs and their meaning.
> Checking the map I have found a "glitch" on my mind: The situation of
> highway=stop and highway=give_way.
> I see traffic_sign=city_limit or traffic_sign=maxspeed but then I see
> highway=stop or highway=give_way. I don't know why these two traffic signs
> are under the tag highway and not the tag traffic_sign itself. Do you know
> why? If you know it , please explain it to me. Thanks.
>
> Also I wish to make a proposal to the community: "translate" all the
> highway=stop and highway=give_way to traffic_sign=stop and
> traffic_sign=give_way.
> What do you think about it ? Let's start the discussion. Thanks for
> reading.
>
> Salut i senyals de trànsit (Health and traffic_signs)
> yopaseopor
>
> ___
> 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] Still RFC — Drop stop positions and platforms

2018-03-31 Thread Jo
highway=platform and railway=platform on a WAY or an AREA are perfectly
fine tags for such platforms, where they exist. Until about a year ago I
was also adding public_transport=platform to these ways, but as it creates
confusion with the platform NODES, which as far as I am concerned represent
the bus and tram stops, I stopped doing that.

https://wiki.openstreetmap.org/wiki/JOSM/Plugins/PT_Assistant/Mapping_Public_Transport_with_JOSM

Jo

2018-03-31 9:23 GMT+02:00 Selfish Seahorse <selfishseaho...@gmail.com>:

> Is public_transport=platform now about the structure or the function?
>
> If it is about the function, then we need a separate tag for the
> platform structure.
>
> If it is about the structure, then we should decide to either map the
> sidewalk or public_transport=platform (depending on how we define a
> platform). Otherwise, we say that there are two physical structures,
> which is wrong.
>
> On 30 March 2018 at 19:41, "Christian Müller" <cmu...@gmx.de> wrote:
> >> Gesendet: Freitag, 30. März 2018 um 11:06 Uhr
> >> Von: "Selfish Seahorse" <selfishseaho...@gmail.com>
> >> An: "Tag discussion, strategy and related tools" <
> tagging@openstreetmap.org>
> >> Betreff: Re: [Tagging] Still RFC — Drop stop positions and platforms
> >>
> >> I wouldn't call a sidewalk a platform, especially because the waiting
> >> area on the sidewalk often isn't clearly delimited. Furthermore,
> >> double tagging doesn't work if the sidewalk is called 'X Road' and the
> >> bus stop 'Y Square'.
> >>
> >
> > If a sidewalk _functions_ as a platform, than you can indeed call that
> > part of the sidewalk a platform, depending on which role of the area
> > you are currently talking about.  This is time-dependent:
> >
> > If lots of people are standing and waiting on that sidewalk for a
> > vehicle to arrive, it will be easier for you to see why this is (also)
> > a platform, than e.g. at night time without a PT service serving the
> > halt.
> >
> > A thing as simple as a box may be used as a table or chair.  This is
> > the same thing here.  You have a physical structure that is so simple
> > that it may function as a platform or a sidewalk, depending on current
> > use.
> >
> >
> > Greetings
> > cmuelle8
> >
> > ___
> > 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] Still RFC — Drop stop positions and platforms

2018-03-30 Thread Jo
I tag the platform as NODE with:

highway=bus_stop
public_transport=platform
bus=yes
name=
ref=
route_ref=
zone=
...

Because nodes have 1 pair of coordinates, so convenient for direct
comparison with external sources and t's easy to draw text around it with
an offset in MapCSS in JOSM,

If there is a platform, I map it as a way or an area:
highway=platform

Only the platform nodes are added to the route relations.

2018-03-30 13:52 GMT+02:00 Selfish Seahorse <selfishseaho...@gmail.com>:

> If I got you right, you map the platform as a
> public_transport=platform way and add a public_transport=platform node
> in addition?
>
> Why not tag that node public_transport=stop then? This would allow for
> a clear distinction between platform and stop.
>
>
> On 30 March 2018 at 11:52, Jo <winfi...@gmail.com> wrote:
> > When tagging platforms as ways, I wouldn't add details like name to
> them, as
> > the name would already be present on the platform node, which represents
> the
> > stop, both for rendering purposes as for being added to the route
> relations.
> >
> > I would only map a platform as a way, if there is tactile paving, or it's
> > higher than the rest of the sidewalk, or if it's clearly an island
> between
> > main road and cycleway. Before we had the bus_bay=right/left/both, I have
> > been adding platform ways in the shape of the bay. Not sure if that is
> the
> > best practice. As I got used to them, I think they render nicely, but it
> may
> > be exaggerated. They are not mapped for the purpose of adding them to the
> > route relations and there is clearly accommodations for the buses near
> such
> > stops. Most of them look like (narrower) sidewalks though.
> >
> > Jo
> >
> >
> >
> > 2018-03-30 11:06 GMT+02:00 Selfish Seahorse <selfishseaho...@gmail.com>:
> >>
> >> > In this case it is not wrong to tag a fraction of the sidewalk as
> >> > platform, there is dual (multipurpose) use in this case.  There are
> several
> >> > variants, sometimes the paving stones suggest a dedicated area over
> full or
> >> > half of the width, sometimes not.  Since the tags do not conflict
> with the
> >> > highway tags, double tagging with highway=footway
> public_transport=platform
> >> > may be a good way to reflect this ground situation.
> >>
> >> I wouldn't call a sidewalk a platform, especially because the waiting
> >> area on the sidewalk often isn't clearly delimited. Furthermore,
> >> double tagging doesn't work if the sidewalk is called 'X Road' and the
> >> bus stop 'Y Square'.
> >>
> >>
> >> On 29 March 2018 at 23:17, "Christian Müller" <cmu...@gmx.de> wrote:
> >> >> Sent: Thu, 29 Mar 2018 19:55:34 +0200
> >> >> From: "Selfish Seahorse" <selfishseaho...@gmail.com>
> >> >> To: "Tag discussion, strategy and related tools"
> >> >> <tagging@openstreetmap.org>
> >> >> Subject: Re: [Tagging] Still RFC — Drop stop positions and platforms
> >> >>
> >> >> Or, very often, because there's a sidewalk and, therefore, no need
> for
> >> >> a platform.
> >> >
> >> > In this case it is not wrong to tag a fraction of the sidewalk as
> >> > platform,
> >> > there is dual (multipurpose) use in this case.  There are several
> >> > variants,
> >> > sometimes the paving stones suggest a dedicated area over full or half
> >> > of
> >> > the width, sometimes not.  Since the tags do not conflict with the
> >> > highway
> >> > tags, double tagging with highway=footway public_transport=platform
> may
> >> > be
> >> > a good way to reflect this ground situation.
> >> >
> >> > This is also a nice way to see, why and where PT tags perform better
> >> > than
> >> > the legacy tagging - a combination like highway=footway
> highway=platform
> >> > won't do.
> >> >
> >> >> Doesn't b) correspond to how public_transport has been defined? 'If
> >> >> there is no platform in the real world, one can place a node at the
> >> >> pole.'
> >> >
> >> > Yes, it corresponds. I remember seeing kv-pages with the node icon
> >> > crossed out.  Currently this (still?) applies e.g. to
> >> > https://wiki.openstreetmap.org/wiki/DE:Tag:railway%3Dplatform
> >> > It may have affected other platform related pages in the past.
> &g

Re: [Tagging] Still RFC — Drop stop positions and platforms

2018-03-30 Thread Jo
When tagging platforms as ways, I wouldn't add details like name to them,
as the name would already be present on the platform node, which represents
the stop, both for rendering purposes as for being added to the route
relations.

I would only map a platform as a way, if there is tactile paving, or it's
higher than the rest of the sidewalk, or if it's clearly an island between
main road and cycleway. Before we had the bus_bay=right/left/both, I have
been adding platform ways in the shape of the bay. Not sure if that is the
best practice. As I got used to them, I think they render nicely, but it
may be exaggerated. They are not mapped for the purpose of adding them to
the route relations and there is clearly accommodations for the buses near
such stops. Most of them look like (narrower) sidewalks though.

Jo



2018-03-30 11:06 GMT+02:00 Selfish Seahorse <selfishseaho...@gmail.com>:

> > In this case it is not wrong to tag a fraction of the sidewalk as
> platform, there is dual (multipurpose) use in this case.  There are several
> variants, sometimes the paving stones suggest a dedicated area over full or
> half of the width, sometimes not.  Since the tags do not conflict with the
> highway tags, double tagging with highway=footway public_transport=platform
> may be a good way to reflect this ground situation.
>
> I wouldn't call a sidewalk a platform, especially because the waiting
> area on the sidewalk often isn't clearly delimited. Furthermore,
> double tagging doesn't work if the sidewalk is called 'X Road' and the
> bus stop 'Y Square'.
>
>
> On 29 March 2018 at 23:17, "Christian Müller" <cmu...@gmx.de> wrote:
> >> Sent: Thu, 29 Mar 2018 19:55:34 +0200
> >> From: "Selfish Seahorse" <selfishseaho...@gmail.com>
> >> To: "Tag discussion, strategy and related tools" <
> tagging@openstreetmap.org>
> >> Subject: Re: [Tagging] Still RFC — Drop stop positions and platforms
> >>
> >> Or, very often, because there's a sidewalk and, therefore, no need for
> >> a platform.
> >
> > In this case it is not wrong to tag a fraction of the sidewalk as
> platform,
> > there is dual (multipurpose) use in this case.  There are several
> variants,
> > sometimes the paving stones suggest a dedicated area over full or half of
> > the width, sometimes not.  Since the tags do not conflict with the
> highway
> > tags, double tagging with highway=footway public_transport=platform may
> be
> > a good way to reflect this ground situation.
> >
> > This is also a nice way to see, why and where PT tags perform better than
> > the legacy tagging - a combination like highway=footway highway=platform
> > won't do.
> >
> >> Doesn't b) correspond to how public_transport has been defined? 'If
> >> there is no platform in the real world, one can place a node at the
> >> pole.'
> >
> > Yes, it corresponds. I remember seeing kv-pages with the node icon
> > crossed out.  Currently this (still?) applies e.g. to
> > https://wiki.openstreetmap.org/wiki/DE:Tag:railway%3Dplatform
> > It may have affected other platform related pages in the past.
> >
> > So this is yet another example of a problem raised earlier: Legacy
> > information lingering in the wiki with sparse reference to the suc-
> > cessor for readers to compare.  As long as a 'deprecated' label is
> > missing, it seems natural to some extent that there is concurrent
> > competition between the older and the newer approach to map PT.
> >
> >
> > Greetings
> > cmuelle8
> >
> > ___
> > 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] Still RFC — Drop stop positions and platforms

2018-03-29 Thread Jo
ough the issue,
> apparently,
> >> was the ability to render based on the mode tags -- which could have
> been
> >> solved with a generic transit icon.)
> >>
> >> A third concern was double-rendering. If both a highway=bus_stop node
> and a
> >> public_transport=platform node exist, won't mappers want to remove the
> >> duplicate? I would hope so! Alternatively, if a stop area is mapped with
> >> both public_transport=platform and public_transport=stop_position,
> won't
> >> that make the map messy? That, it seems to me, is a valid
> consideration. It
> >> was proposed to NOT render public_transport=stop_position in all cases,
> >> which frankly I agree with when the node is on a highway (not clear to
> me
> >> when it's on a railway, as I don't have experience there).
> >>
> >> The last issue, raised by kocio-pl, who I assume is Daniel Koć of this
> >> thread, is that someone needs to write the code.
> >>
> >>
> >>
> >>
> >> On Thu, Mar 29, 2018 at 3:56 AM, Daniel Koć <daniel@koć.pl> wrote:
> >>>
> >>> W dniu 28.03.2018 o 18:42, Jo pisze:
> >>> > I've tried to accomplish that many years ago already, it failed. The
> >>> > people at the helm of the rendering stack consider the 'old' tags
> good
> >>> > enough and the new scheme somehow not explicit enough, hence the
> >>> > double tagging.
> >>>
> >>> I'm not sure who do you mean, but I certainly want to make it render on
> >>> osm-carto. It wasn't possible before we have hstore few months ago
> >>> (v4.0.0+) and I had to learn coding with this feature enabled, but now
> >>> it's much closer to being reality - I need just some time probably, but
> >>> any help is welcome. Related issue:
> >>>
> >>> https://github.com/gravitystorm/openstreetmap-carto/issues/435
> >>>
> >>> > Dropping the tags you call obsolete from the data, is not an option
> as
> >>> > far as I'm concerned. Part of the reason for mapping bus stops, is to
> >>> > get them rendered on the map. That's not tagging for the renderer,
> >>> > that's merely being practical and adapting to the situation at hand.
> >>>
> >>> Tagging for rendering is confusing slogan. There's nothing wrong in the
> >>> literal sense, the problem is with faking data just to show something
> on
> >>> the map. Double tagging is a problem too, but transition is always
> >>> troublesome process.
> >>>
> >>> --
> >>> "My method is uncertain/ It's a mess but it's working" [F. Apple]
> >>>
> >>>
> >>>
> >>> ___
> >>> Tagging mailing list
> >>> Tagging@openstreetmap.org
> >>> https://lists.openstreetmap.org/listinfo/tagging
> >>
> >>
> >>
> >> ___
> >> Tagging mailing list
> >> Tagging@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/tagging
> >>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Still RFC — Drop stop positions and platforms

2018-03-29 Thread Jo
PT v2 says you CAN map stops using 2 objects. People reading that
understood that you MUST use both a stop_position node and a platform
way/node.

Then it was interpreted as: both of those HAVE TO be added to the route
relations.

To make things look consistent in the route relations, then some mappers
started adding platform ways where no actual platforms exist.

All in all the scheme, when interpreted like that, is too complex.
Information is duplicated across several objects, creating a need to keep
them in sync afterwards, whichj is, of course absurd.

Personally I don't see a need for the stop_position nodes, so for the few
ones that I do add, they don't get details like name, and I don't add them
to the route relations.

Also the route relations, it's not one per direction of travel. It's one
per variation of itinerary, which often comes down to 2 relations per
route_master relation, but it can also be just 1, or up to 50 (
https://www.openstreetmap.org/relation/3944387). For "telescopic"
lines, I only create route relations for the longer variants. The whole
thing is messy enough as it is.

Polyglot

2018-03-29 9:37 GMT+02:00 Topographe Fou :

> Hi,
>
> Your intent is to simplify but I don't understand how replacing one tag by
> three or more with different syntaxes key/value according to the type of
> transportation and their introduction in OSM can make things easier.
>
> I share your view when you say that two schemas is too much to maintain
> but I would rather jump to the conclusion that it is PTv1 which should be
> dropped if we want to drop one as it has limitations. PTv2 is not that
> complexe, it is public transportation which are complexe to map.
>
> One thing I never understood was why we have to maintain two schemas
> (probably because consensus was not reached). I guess this is the main
> reason why some people (especially new mappers) can be lost. And also why
> wiki can sometime say one thing or the opposite. I think it delayed the
> evolution of renderers and tools instead of pushing them to evolve with the
> schemas. I have the feeling that your analysis dropped those factors. Once
> the map on osm.org will render PTv2, I'm sure it will be a huge step and
> that all the work done will pay.
>
> Then I don't see where is the difficulty to map two different features
> instead of mapping a single approximate one. It means more work, right, but
> it adds more values to the project as a whole. And since nobody is forced
> to mapped everything on its own...
>
> To conclude: I disagree with part of the analysis and with the whole
> conclusion.
>
> Yours,
>
> LeTopographeFou
>
>   Message original
> De: i...@zverev.info
> Envoyé: 28 mars 2018 3:54 PM
> À: tagging@openstreetmap.org
> Répondre à: tagging@openstreetmap.org
> Objet: [Tagging] Still RFC — Drop stop positions and platforms
>
> Hi folks,
>
> A while ago I've made a proposal to deprecate some public_transport=* tags:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/
> Drop_stop_positions_and_platforms
>
> The discussion was very slow, and in general mappers seemed to accept the
> change. I'd like to push this to voting in a few days, but first I want to
> know if somebody has anything to say about the proposal. Like, why we
> should not. I'd prefer to discuss that before the voting has started.
>
> Ilya
> ___
> 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] Still RFC — Drop stop positions and platforms

2018-03-28 Thread Jo
>
> Yes. I like it as well. But it still could be improved. E.g. I'm thinking
> about tool which - If you create four objects: two nodes on highway and two
> nodes/ways beside highway and select all of them - will automatically tag
> them as stop_position and platform and will create corresponding
> public_transport relation. I have to find a time to develop it.
>
If you need that functionality, I can have it added to JOSM's PT_Assistant
plugin. It already has a map mode to add stop_position nodes on ways and
creating a preset that adds/removes specific tags to nodes is also
relatively simple to do.

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


Re: [Tagging] Still RFC — Drop stop positions and platforms

2018-03-28 Thread Jo
I've tried to accomplish that many years ago already, it failed. The people
at the helm of the rendering stack consider the 'old' tags good enough and
the new scheme somehow not explicit enough, hence the double tagging.

Dropping the tags you call obsolete from the data, is not an option as far
as I'm concerned. Part of the reason for mapping bus stops, is to get them
rendered on the map. That's not tagging for the renderer, that's merely
being practical and adapting to the situation at hand.

Adding public_transport=platform/stop_position is also being practical, as
they are treated in certain ways by JOSM, with regard to assignment of
roles.

I stopped worrying about the wasted disk space or processing power several
years ago.

Polyglot



2018-03-28 17:48 GMT+02:00 Marián Kyral :

>
> -- Původní e-mail --
> Od: "Christian Müller" 
> Komu: tagging@openstreetmap.org
> Datum: 28. 3. 2018 16:22:41
> Předmět: Re: [Tagging] Still RFC — Drop stop positions and platforms
>
> > Sent: Wed, 28 Mar 2018 16:53:28 +0300
> > From: "Ilya Zverev" 
> > To: tagging@openstreetmap.org
> > Subject: [Tagging] Still RFC — Drop stop positions and platforms
> >
> > Hi folks,
> >
> > A while ago I've made a proposal to deprecate some public_transport=*
> tags:
> >
> > https://wiki.openstreetmap.org/wiki/Proposed_features/
> Drop_stop_positions_and_platforms
> >
>
> In your proposal you complain about subjectively felt things like "history
> won't go away", but at the same time you are trying to revert a part of
> history itself - "the public_transport tags are seven years old now". Many
> people were involved creating those tags, they are well understood and
> discriminate the features they describe in a thoroughly documented and
> plausible way.
>
> Just because a lot of deprecated tags have not vanished in favor of the
> new ones yet does not mean there is a preference on the deprecated tags. A
> lot of users and apps have adopted the new public_transport tags. It simply
> does not make any sense to do a rollback on these for the observation of a
> sluggish adoption/transition rate.
>
>
> I fully agree with this.
>
>
> I'm still waiting for full support of new public_transport schema on maps
> (especially on the "transport" layer on osm.org) and decommission of the
> old schema. Still no progress on it.. Instead, we still have to use
> obsolete tags like highway=bus_stop to see stops on the map. It is mapping
> for render I think and we should stop doing it, convert old schema objects
> to new schema (a MapRoulette task?) and use only new schema.
>
>
> I think the new schema is really good and should be fully implemented. It
> means have support in editors and renderers.
>
>
> Marián
>
>
> ___
> 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] Still RFC — Drop stop positions and platforms

2018-03-28 Thread Jo
I'm not very optimistic you'll manage to get that proposal to pass.

We'll probably keep double tagging everything for a long time to come. The
reason why I put public_transport=platform on bus stop nodes, is that JOSM
conveniently adds a platform role when they are added to relations. Also
because it felt like the right thing to do, after the public_transport
scheme was voted on. But as it doesn't seem that they will ever be rendered
on the standard rendering, we have to add
highway=bus_stop/railway=tram_stop anyway. I gave up on trying to change
that many years ago.

The reason why I add stop_position nodes at the start and end of the
itineraries, is because I want to split the way there. For me those nodes
don't serve any other purpose, but I'm mostly mapping bus routes (And the
tram routes according to the same scheme).

What we need to find a solution for is that some mappers want to add each
stop to the route relations multiple times for each and every variation of
the itinerary. Once as a stop_position node and once as the way they drew
for the platform. For "consistency" I sometimes see that platform ways are
added even where no platform is present in reality.

Representing the stops as nodes next to the way solves all that. It might
be easier to propose a new tag for those nodes though, could be
public_transport=passengers / halt / pole, than to try to abolish
platform/stop_position.

In the mean time I'll keep tagging them as;
highway=bus_stop
public_transport=platform
bus=yes
+ details

and
railway=tram_stop
public_transport=platform
tram=yes
+ details

I don't think they add a lot of complexity. It's a bit awkward we have
explain that we have all these shiny "new" tags for a consistent scheme,
but we have to keep using the "old" ones, if we want to get stops rendered
too. I don't mind dropping them, and at the same time I don't mind to keep
using them.

What I do mind is to add more than 1 object to the route relations per
stop. But I'll keep making sure tools like PT_Assistant can cope with that
added complexity.

Polyglot


2018-03-28 16:21 GMT+02:00 "Christian Müller" :

> > Sent: Wed, 28 Mar 2018 16:53:28 +0300
> > From: "Ilya Zverev" 
> > To: tagging@openstreetmap.org
> > Subject: [Tagging] Still RFC — Drop stop positions and platforms
> >
> > Hi folks,
> >
> > A while ago I've made a proposal to deprecate some public_transport=*
> tags:
> >
> > https://wiki.openstreetmap.org/wiki/Proposed_features/
> Drop_stop_positions_and_platforms
> >
>
> In your proposal you complain about subjectively felt things like "history
> won't go away", but at the same time you are trying to revert a part of
> history itself - "the public_transport tags are seven years old now".  Many
> people were involved creating those tags, they are well understood and
> discriminate the features they describe in a thoroughly documented and
> plausible way.
>
> Just because a lot of deprecated tags have not vanished in favor of the
> new ones yet does not mean there is a preference on the deprecated tags.  A
> lot of users and apps have adopted the new public_transport tags.  It
> simply does not make any sense to do a rollback on these for the
> observation of a sluggish adoption/transition rate.
>
> The proposal has been long thought about and delivers, in itself, a
> coherent way of tagging public transport infrastructure.  It has learned
> from previous tags, it is thus a refinement of the previous tagging.  There
> will be lots of people -unheared and not- that oppose breaking a (slow
> moving) transition process at this point in time.  Just be patient and give
> it some more years.
>
> You could help and promote the adoption, instead of dilating it.  A lot of
> rural area data has not been touched for years, waiting for you to do
> research and remapping efforts.
>
>
> Greetings
> cmuelle8
>
> ___
> 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] Tagging request: missing admin_level tags

2018-03-12 Thread Jo
Except of course, when the boundary is disputed, then there might be
overlap and possibly even holes of no man's land?

Polyglot

2018-03-12 13:41 GMT+01:00 Dave F :

> OK, I understand what you're trying to highlight, but don't see it as
> relevant to this thread.
> But anyway, the "boundary between two countries" can be distinguished as
> they'll have two relations with boundary data whereas "the high seas"
> boundary will only have one.
>
> DaveF.
>
> On 12/03/2018 00:17, Christoph Hormann wrote:
>
>> On Monday 12 March 2018, Dave F wrote:
>>
>>> and it would not distinguish between the outer boundaries (towards
 the high seas)
 and the boundaries between two countries.

>>> Unsure what you mean. Could you elaborate, Example?
>>>
>>> Sure:
>>
>> https://www.openstreetmap.org/way/96104334
>>
>> is an outer maritime boundary at 12 mile distance from the baseline
>> separating the territorial waters from the high seas.
>>
>> OTOH
>>
>> https://www.openstreetmap.org/way/54749533
>>
>> is a maritime boundary between two countries.
>>
>> You might say this difference is not of practical importance for data
>> users but there are for example many maps which generally do not show
>> the first type of boundary but which do show (at least partly) the
>> second type of boundary.  Like this:
>>
>> http://legacy.lib.utexas.edu/maps/cia16/denmark_sm_2016.gif
>>
>> You can of course determine this difference from the spatial
>> relationship of the boundary relations.
>>
>>
>
> ___
> 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] Tagging request: missing admin_level tags

2018-03-10 Thread Jo
I added many borders in Uganda a few years ago, they are gray in your
rendering. Should I go and put admin_level tags on them now? For the
highest or the lowest admin_level they are part of?

Or a semicolon separated list...?

Seems like a step backward to me, but I guess, whatever works.

Polyglot

2018-03-10 10:15 GMT+01:00 Christoph Hormann :

> On Saturday 10 March 2018, Matthijs Melissen wrote:
> > [...] This has a number of advantages -
> > for example, it will make it possible to style maritime boundaries
> > differently.
>
> I have already strongly voiced by opinion on this in the style
> development discussion:
>
> https://github.com/gravitystorm/openstreetmap-
> carto/pull/2950#issuecomment-345839634
> https://github.com/gravitystorm/openstreetmap-
> carto/pull/3074#issuecomment-368227660
> https://github.com/gravitystorm/openstreetmap-
> carto/pull/3102#issuecomment-370394640
>
> But i want to add here that the statement cited above is simply wrong.
> There are lots of ways you can style maritime boundaries differently -
> some of them are difficult using the tool chain currently used by
> OSM-Carto, others come with design restrictions - just like the status
> quo in the style or the method you are planning to use.  But the idea
> that this approach is without good alternatives is a misapprehension of
> the situation.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> 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] Culverts and Fords

2018-03-01 Thread Jo
the water is tunneling under the road, through a narrow passage. It's not
the road that goes through a tunnel.

2018-03-01 17:40 GMT+01:00 Vao Matua :

> Thank you all for the explanations.
> I think that my issue might have to do with UK English usage.  I  would
> never call a road tunnel a "culvert", I  typically only work and map in a
> rural setting and a culvert is only a passage way for water, and is only
> used at a road or path crossing.
>
> While a ford is something shared by a road and a stream one is still under
> the other, but the rules for rendering assume that the road is underneath.
> In the OSM ford wiki  one
> photograph shows the path on top of the ford using the stepping stones.
> The Wikipedia reference cited on
> the OSM culvert wiki
>  only shows
> stream examples.
> Therefore, why not have a rendering rule for culverts in the same way
> there is a rendering for a ford?
>
> This has been an interesting thought process and I'm probably just lazy
> not wanting to split a watercourse twice and add a tag to the way as
> opposed to snapping a road or watercourse node and adding a tag to the node.
>
> Keep mapping
>
> On Wed, Feb 28, 2018 at 5:11 PM, Dave Swarthout 
> wrote:
>
>> >If 2 ways share a node, then they must be connected to each other. ie on
>> the same layer. So one can't be above/below the other. A road and a stream
>> crossing on the same layer is a ford.
>> >If you tag the shared node as a tunnel, then you don't know which way
>> goes through the tunnel.  Does the stream go through a tunnel, or does the
>> road go through a tunnel, or both?
>>
>> >It is much more useful to map tunnels/bridges as a way. If you know
>> there is a tunnel, but don't know how long the tunnel is, you can estimate
>> it. ie based on the width of the road. You can add a note to say the exact
>> >length/position is estimated
>>
>> Excellent explanation. Agree totally.
>>
>> On Thu, Mar 1, 2018 at 7:48 AM, Craig Wallace 
>> wrote:
>>
>>> On 2018-02-28 23:21, Vao Matua wrote:
>>>
 François

 I don't have an example.  I was trying to think of an example where
 layer would be needed for a stream/road crossing.  A pipe would probably be
 a better example.

 Sorry to cause a distraction.

 My real question is "Why not allow tunnel=culvert to be a node?"

 Emmor

>>>
>>> If 2 ways share a node, then they must be connected to each other. ie on
>>> the same layer. So one can't be above/below the other. A road and a stream
>>> crossing on the same layer is a ford.
>>> If you tag the shared node as a tunnel, then you don't know which way
>>> goes through the tunnel.  Does the stream go through a tunnel, or does the
>>> road go through a tunnel, or both?
>>>
>>> It is much more useful to map tunnels/bridges as a way. If you know
>>> there is a tunnel, but don't know how long the tunnel is, you can estimate
>>> it. ie based on the width of the road. You can add a note to say the exact
>>> length/position is estimated.
>>>
>>>
>>> ___
>>> 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
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] railway=platform nodes at tram stops

2018-02-20 Thread Jo
railway=platform unambiguously refers to an actual platform, mapped as a
way or as an area.

public_transport=platform + tram=yes (+railway=tram_stop) can be mapped on
an isolated node (so not part of the railway=* way).

It would be my preference to ONLY map it on (isolated) nodes. That's what I
do for bus stops public_transport=platform + bus=yes (+highway=bus_stop).
Nodes should be preferred, as they have coordinates. And all the extra
details like name, ref, route_ref, operator, network, zone should be mapped
ONCE on these nodes.

If we can move to such a scheme it would simplify public transport mapping
in OSM a lot.

At some point it was decided to use public_transport=stop_position for a
node which is part of the highway/railway and public_transport=platform for
the isolated node next to the highway where the passengers wait. Maybe it
would have been better to use public_transport=pole for this purpose, or
public_transport=passengers or
public_transport=abstract_approximate_position_on_node_next_to_way_containing_all_the_details_for_this_stop_and_these_are_the_nodes_that_represent_the_stops_in_the_route_relations.
But we use public_transport=platform, regardless of whether an actual
platform is present.

If there is an actual platform, it can be mapped as a way or area, with
possibly tactile_paving=yes, wheelchair=yes, but no need to repeat the name
on them and no need to add them to the route relations. They can be added
to stop_area relations.

Polyglot

2018-02-20 22:28 GMT+01:00 Selfish Seahorse :

> > in osm, platform is where people wait to take the train.
> > people always are "somewhere" before taking the train.
> > osm platform <> irl plateform
>
> Do you mean `public_transport=platform` [^1], `railway=platform` [^2] or
> both?
>
> If `railway=platform` means the same as `public_transport=platform`,
> then the wiki page about `railway=platform` needs an update, because
> it currently reads 'a railway platform'.
>
> [^1]:  >
> [^2]: 
>
> >  > how can we know whether there is a platform?
> >
> > by geometry. if it's a way, it is a "real" plaform.
> > if not, it's unknown.
>
> 'Unknown' means we don't know anything. If `railway=platform` really
> is identical to `public_transport=platform` this would mean that there
> is no way to define that there is no platform.
>
> > maybe a better value should be "embarkation point" but it's "too late"
> > to change a so common value.
>
> Why not just 'stop'?
>
> It's never too late to correct a mistake ...
>
>
> On 20 February 2018 at 22:11, marc marc  wrote:
> > Le 20. 02. 18 à 21:50, Selfish Seahorse a écrit :
> >> On 20 February 2018 at 21:24, marc marc 
> wrote:
> >>> Le 20. 02. 18 à 21:17, Selfish Seahorse a écrit :
>  If no one objects, I'd like to change the wiki page [^1] so that
>  `railway=platform` should not be used on nodes.
> >>>
> >>> I objets and request to do the opposite :
> >>> remove the "forbiden" node for railway=platform
> >>>
> >>> in almost all osm objects, it makes sense to use a node if
> >>> you don't know the precise geometry or if the object has
> >>> a small geometry
> >>> or
> >>> allow to use a way when a more precise geometry is desired.
> >>
> >> I'm sorry, I wasn't precise: I'd like to change the wiki page so that
> >> `railway=platform` should not be mandatory for tram stops without
> >> platform.
> >
> > in osm, platform is where people wait to take the train.
> > people always are "somewhere" before taking the train.
> > osm platform <> irl plateform
> > maybe a better value should be "embarkation point" but it's "too late"
> > to change a so common value.
> >
> >  > how can we know whether there is a platform?
> >
> > by geometry. if it's a way, it is a "real" plaform.
> > if not, it's unknown.
> >
> > Regards,
> > Marc
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] reviving hollow way

2018-02-19 Thread Jo
https://en.wiktionary.org/wiki/holloway

2018-02-19 21:20 GMT+01:00 Steve Doerr :

> On 19/02/2018 09:00, Philip Barnes wrote:
>
> As a native English speaker I have never heard the term Hollow Way,
>> however reading the description it seems that this proposal is describing
>> what is called a Sunken Lane.
>>
>
> Might need a bit more research as both are fairly obscure terms, I would
> imagine. For what it's worth, 'hollow-way' [sic] is mentioned in the Oxford
> English Dictionary, while 'sunken lane' isn't, as far as I can see.
>
> --
> Steve
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
>
> ___
> 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] Nonbreakable spaces in name tags

2018-01-26 Thread Jo
I think it would be best to make the tools we use JOSM, Overpass API, iD,
etc. Unicode aware, so they can handle this correctly.

Polyglot

2018-01-26 16:50 GMT+01:00 Matej Lieskovský :

> @marc: I just realized - I'm not talking about breaking words between
> syllables but about breaking lines between words. It is not adding a
> character, just using a nonbreakable version of a space. Sorry if I'm
> not being clear.
>
> On 26 January 2018 at 16:47, Matej Lieskovský
>  wrote:
> > In Czech, a nonbreakable space should follow any single-letter
> > preposition or conjunction and academic or military titles. A
> > nonbreakable space should also be used due to some common
> > contractions, between a number and a unit, and around some punctuation
> > marks.
> >
> > I noticed that some Overpass queries were not returning some elements
> > - that is how I found out that we actually have a rather large number
> > of nonbreakable spaces in the data.
> >
> > Nonbreakable spaces are currently quite troublesome - not all
> > consumers actually use Unicode collation, it is invisible in JOSM and
> > it is not exactly easy to input. Also, the chance that we convince all
> > contributors to use it correctly is exactly zero. Along with this
> > potentially being "tagging for the renderer", there are many calls for
> > a mass-removal.
> >
> > On the other hand, there is software that actually handles Unicode
> > collation well and it does make the correct rendering of names an
> > order of magnitude easier. Leaving this up to the renderer sounds
> > logical, but imagine forcing every renderer to figure out what
> > language any given name is in and then running the appropriate
> > subprogram to fill in the nonbreakable spaces. This could require
> > semantic analysis due to the need to add a nonbreakable space after
> > the "V" in "V jámě" (preposition) but before the "V" in "Jiří V."
> > (roman ordinal number) and after the "V." in "V. Špidla" (contraction
> > of name (and yes, there are cases when you should use a contraction)).
> >
> > Nonbreakable spaces are strange - you cannot reliably tell if they are
> > used OTG (but in some cases you can), official documents often ignore
> > them (leaving them up to the automated systems in office software, so
> > they do occur sometimes) and the rules governing them are older than
> > computers, so asking if they are a rule or a character is... dubious.
> >
> > And yes, we do have really long names of things. Names of POIs named
> > after people are a common use case.
> >
> > Matej
> >
> > On 26 January 2018 at 16:11, marc marc 
> wrote:
> >> Le 26. 01. 18 à 15:48, Matej Lieskovský a écrit :
> >>> Several Slavic languages have rather formal rules about line breaks.
> >>
> >> it depends on whether it is a grammar rule or a "char".
> >> In French, it is a rule to know how to cut a word at the end of a line.
> >> Since it's a grammar rule, I don't see any point in adding a character
> >> between syllables to describe it. it's up to the render
> >> to know when it can do it if ppl wants this feature.
> >> I know nothing about your language, but I feel it look like the same.
> >> If my understanding is correct, I am in favour of not putting
> >> this "nonbreakable" information into a value and moving it to app code
> >> that need it (witch ? have you so long value that's needed to break it
> >> in several line ?)
> >>
> >> Regards,
> >> Marc
> >> ___
> >> Tagging mailing list
> >> Tagging@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


  1   2   3   >