Re: [Tagging] Clarification unclassified vs residential

[djakk djakk]

Hello Mateusz,

You can not render correctly with a bad tagging, and that is the case here
: in France, a trunk road have 2 lanes and oneway=yes by default, not in
UK.

I understand your criticism about the values I’ve used, it is not
definitive :).

Except maybe the values for road_level : they should be like the values of
admin_level.


Julien “djakk”



Le dim. 3 mars 2019 à 20:21, Mateusz Konieczny  a
écrit :

> "I would have expected the first road be rendered not like the 3 last
> roads,
> those last 3 roads should have been rendered the same as they look the
> same"
>
> Is it tagging or rendering discussion?
>
> Because as far as as rendering is concerned you can already do that, just
> use surface/lanes/oneway tags.
>
> In general highway=* tag is not about how road looks like, it is rather
> about its
> importance in road system (with sole exception of highway=motorway).
>
> It is hard to be sure without real proposal but I am not fan of tags like
> looks_like=FR_urban_motorway or road_class=UK_motorway
>
> And I am against tags like importance_local=5 or road_level=1.
> Numeric values in tracktype=* were a mistake, it is really hard to
> remember
> what is the difference between tracktype=grade3 and tracktype=grade4.
>
> Mar 3, 2019, 7:02 PM by djakk.dj...@gmail.com:
>
> Hello !
>
> I’ve updated
> https://wiki.openstreetmap.org/wiki/User:Djakk/new_tagging_scheme_for_roads
>
> To answer the original question of this thread, I wish you can use
> importance_local=5 or 6 with abutters=rural or residential ;)
>
>
> ___
> 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] Clarification unclassified vs residential

[djakk djakk]

Hello !

I’ve updated
https://wiki.openstreetmap.org/wiki/User:Djakk/new_tagging_scheme_for_roads

To answer the original question of this thread, I wish you can use
importance_local=5 or 6 with abutters=rural or residential ;)


Julien “djakk”



Le dim. 3 mars 2019 à 01:01, Sergio Manzi  a écrit :

>
> On 2019-03-03 00:49, Mark Wagner wrote:
> > On Sat, 2 Mar 2019 02:05:46 +0100
> > Sergio Manzi  wrote:
> >
> >> On 2019-03-02 01:33, Martin Koppenhoefer wrote:
> >>> sent from a phone
> >>>
>  On 1. Mar 2019, at 13:45, Mateusz Konieczny
>   wrote:
> 
>  I would tag max weight, I would not tag emergency=no.
> >>> +1, it will not exclude all kinds of emergency services anyway,
> >>> only those in vehicles that are too heavy, for example there could
> >>> be police on bicycles who could cycle on the bridge like
> >>> pedestrians can walk on it.
> >>>
> >>>
> >>> Cheers, Martin
> >>
> >> I really-really-really like to know of a place where emergency
> >> vehicles are *legally *not allowed to go...
> > It's not "legally not allowed to go", but on Fairchild Air Force Base,
> > civilian emergency vehicles are subject to the same "with permission
> > only" restriction as everyone else.  I suspect the same is true of most
> > if not all other military bases in the United States.
>
>
> I also suspect guards of the US Bullion Depository at Fort Knox will not
> just open the gates to an unexpected ambulance even if it had full light
> flashing and siren wailing. Or will they? Maybe a good idea worth trying...
>
>
>
>
> ___
> 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] Clarification unclassified vs residential

[djakk djakk]

Hello ! So I have written something on the wiki :
https://wiki.openstreetmap.org/wiki/User:Djakk/new_tagging_scheme_for_roads

It is not definitive, feel free to add new ideas or to criticize ;)

Julien “djakk”


Le lun. 25 févr. 2019 à 11:36, djakk djakk  a écrit :

> I meant “road for hgv” not “road for hybrid” ^^
>
> Julien “djakk”
>
>
> Le lun. 25 févr. 2019 à 11:35, djakk djakk  a
> écrit :
>
>> I forgot to mention that there are several kind of road to class :
>> footway, cycleway, road for cars, road for hybrid, road for psv ;)
>>
>> Julien “djakk”
>>
>>
>> Le lun. 25 févr. 2019 à 10:55, Erkin Alp Güney 
>> a écrit :
>>
>>> Service roads would be highway=service as it is now.
>>>
>>> road_level tag also solves non-primary motorway tagging (motorroad,
>>> autovia, non-expressway freeway, Polish S-road, Russian limited access
>>> A-road etc.). You would tag a non-primary motorway as highway=motorway
>>> road_level=.
>>>
>>> 25.02.2019 00:20 tarihinde Graeme Fitzpatrick yazdı:
>>> >
>>> >
>>> > On Mon, 25 Feb 2019 at 00:27, djakk djakk >> > <mailto:djakk.dj...@gmail.com>> wrote:
>>> >
>>> > Hello !
>>> >
>>> > I think we should decorrelate the attributes of a road : its
>>> > administrative class, its importance in the road network (at least
>>> > 5 levels), its physical characteristics (motorway-like, two large
>>> > lanes, link=yes ...), possibly its traffic characteristics.
>>> >
>>> > So we can tag a secondary motorway or a primary road through a
>>> > residential area or an official motorway with pedestrians actually
>>> > walking on it.
>>> >
>>> > So that we’ll unify osm road classification through the world
>>> > (remember the highway=trunk issue ;-))
>>> >
>>> >
>>> > I could see that working!
>>> >
>>> > Replace the existing highway= types (=motorway; =primary etc) with
>>> > highway=1 to =5?, with 1 being the existing =motorway, down to 5 being
>>> > all the minor streets in a town.
>>> >
>>> > If you have a look
>>> > at https://www.openstreetmap.org/#map=13/-28.0643/153.4191 (& I'm
>>> > pretty sure everywhere around the World will look fairly similar?),
>>> > the pink Pacific Motorway (=motorway) would become =1; the orange /
>>> > tan major arterial roads (=primary: 2; 3; 7; 40; 50) =2; yellow
>>> > connecting roads (=secondary) =3; white roads through suburbs
>>> > (=tertiary) =4; all the grey minor roads (=residential /
>>> > unclassified): residential in the suburbs, commercial areas in the
>>> > CBD, roads inside industrial areas etc =5.
>>> >
>>> > Would you need =6 for service roads (driveways, parking lanes etc), or
>>> > would they stay as the current=service designation?
>>> >
>>> > Setting levels like this & rendering them this way, would also get rid
>>> > of the problem of roads not being visible in remote areas because a
>>> > "secondary" road won't render - even if it's only hard-packed dirt, it
>>> > would still be the level 1 or 2 road in this area!
>>> >
>>> > Feasible?
>>> >
>>> > Thanks
>>> >
>>> > Graeme
>>> >
>>>
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Clarification unclassified vs residential

[djakk djakk]

I meant “road for hgv” not “road for hybrid” ^^

Julien “djakk”


Le lun. 25 févr. 2019 à 11:35, djakk djakk  a écrit :

> I forgot to mention that there are several kind of road to class :
> footway, cycleway, road for cars, road for hybrid, road for psv ;)
>
> Julien “djakk”
>
>
> Le lun. 25 févr. 2019 à 10:55, Erkin Alp Güney  a
> écrit :
>
>> Service roads would be highway=service as it is now.
>>
>> road_level tag also solves non-primary motorway tagging (motorroad,
>> autovia, non-expressway freeway, Polish S-road, Russian limited access
>> A-road etc.). You would tag a non-primary motorway as highway=motorway
>> road_level=.
>>
>> 25.02.2019 00:20 tarihinde Graeme Fitzpatrick yazdı:
>> >
>> >
>> > On Mon, 25 Feb 2019 at 00:27, djakk djakk > > <mailto:djakk.dj...@gmail.com>> wrote:
>> >
>> > Hello !
>> >
>> > I think we should decorrelate the attributes of a road : its
>> > administrative class, its importance in the road network (at least
>> > 5 levels), its physical characteristics (motorway-like, two large
>> > lanes, link=yes ...), possibly its traffic characteristics.
>> >
>> > So we can tag a secondary motorway or a primary road through a
>> > residential area or an official motorway with pedestrians actually
>> > walking on it.
>> >
>> > So that we’ll unify osm road classification through the world
>> > (remember the highway=trunk issue ;-))
>> >
>> >
>> > I could see that working!
>> >
>> > Replace the existing highway= types (=motorway; =primary etc) with
>> > highway=1 to =5?, with 1 being the existing =motorway, down to 5 being
>> > all the minor streets in a town.
>> >
>> > If you have a look
>> > at https://www.openstreetmap.org/#map=13/-28.0643/153.4191 (& I'm
>> > pretty sure everywhere around the World will look fairly similar?),
>> > the pink Pacific Motorway (=motorway) would become =1; the orange /
>> > tan major arterial roads (=primary: 2; 3; 7; 40; 50) =2; yellow
>> > connecting roads (=secondary) =3; white roads through suburbs
>> > (=tertiary) =4; all the grey minor roads (=residential /
>> > unclassified): residential in the suburbs, commercial areas in the
>> > CBD, roads inside industrial areas etc =5.
>> >
>> > Would you need =6 for service roads (driveways, parking lanes etc), or
>> > would they stay as the current=service designation?
>> >
>> > Setting levels like this & rendering them this way, would also get rid
>> > of the problem of roads not being visible in remote areas because a
>> > "secondary" road won't render - even if it's only hard-packed dirt, it
>> > would still be the level 1 or 2 road in this area!
>> >
>> > Feasible?
>> >
>> > Thanks
>> >
>> > Graeme
>> >
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Clarification unclassified vs residential

[djakk djakk]

I forgot to mention that there are several kind of road to class : footway,
cycleway, road for cars, road for hybrid, road for psv ;)

Julien “djakk”


Le lun. 25 févr. 2019 à 10:55, Erkin Alp Güney  a
écrit :

> Service roads would be highway=service as it is now.
>
> road_level tag also solves non-primary motorway tagging (motorroad,
> autovia, non-expressway freeway, Polish S-road, Russian limited access
> A-road etc.). You would tag a non-primary motorway as highway=motorway
> road_level=.
>
> 25.02.2019 00:20 tarihinde Graeme Fitzpatrick yazdı:
> >
> >
> > On Mon, 25 Feb 2019 at 00:27, djakk djakk  > <mailto:djakk.dj...@gmail.com>> wrote:
> >
> > Hello !
> >
> > I think we should decorrelate the attributes of a road : its
> > administrative class, its importance in the road network (at least
> > 5 levels), its physical characteristics (motorway-like, two large
> > lanes, link=yes ...), possibly its traffic characteristics.
> >
> > So we can tag a secondary motorway or a primary road through a
> > residential area or an official motorway with pedestrians actually
> > walking on it.
> >
> > So that we’ll unify osm road classification through the world
> > (remember the highway=trunk issue ;-))
> >
> >
> > I could see that working!
> >
> > Replace the existing highway= types (=motorway; =primary etc) with
> > highway=1 to =5?, with 1 being the existing =motorway, down to 5 being
> > all the minor streets in a town.
> >
> > If you have a look
> > at https://www.openstreetmap.org/#map=13/-28.0643/153.4191 (& I'm
> > pretty sure everywhere around the World will look fairly similar?),
> > the pink Pacific Motorway (=motorway) would become =1; the orange /
> > tan major arterial roads (=primary: 2; 3; 7; 40; 50) =2; yellow
> > connecting roads (=secondary) =3; white roads through suburbs
> > (=tertiary) =4; all the grey minor roads (=residential /
> > unclassified): residential in the suburbs, commercial areas in the
> > CBD, roads inside industrial areas etc =5.
> >
> > Would you need =6 for service roads (driveways, parking lanes etc), or
> > would they stay as the current=service designation?
> >
> > Setting levels like this & rendering them this way, would also get rid
> > of the problem of roads not being visible in remote areas because a
> > "secondary" road won't render - even if it's only hard-packed dirt, it
> > would still be the level 1 or 2 road in this area!
> >
> > Feasible?
> >
> > Thanks
> >
> > Graeme
> >
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Clarification unclassified vs residential

[djakk djakk]

Yes it must be additional tags, so that existing tools that use
openstreetmap do not get lost :)

I’ll try to write this on my wiki’s page in the next days ...



Julien “djakk”


Le lun. 25 févr. 2019 à 00:30, Martin Koppenhoefer 
a écrit :

>
>
> sent from a phone
>
> > On 24. Feb 2019, at 22:20, Graeme Fitzpatrick 
> wrote:
> >
> > Replace the existing highway= types (=motorway; =primary etc) with
> highway=1 to =5?, with 1 being the existing =motorway, down to 5 being all
> the minor streets in a town.
>
>
> rather than replacing the highway tags I would suggest to add tags for
> properties which we want to describe and „can“ not yet. It is very hard to
> often impossible to get back to individual properties from generalized
> information. The highway class is such a generalized tag, the categories
> summarize different properties of a road, focusing on the network. It
> served us quite well, but it doesn’t provide answers for specific
> legal/technical questions, like which is the road class according to local
> planning authorities, or which is the network class in the national system.
> These could be additional tags
>
> 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] Clarification unclassified vs residential

[djakk djakk]

Okay I found it ! May 2018 ;)

Julien “djakk”


Le dim. 24 févr. 2019 à 19:11, djakk djakk  a écrit :

> Erkin, when did you make this proposal ?
>
> Julien
>
>
> Le dim. 24 févr. 2019 à 18:31, Erkin Alp Güney  a
> écrit :
>
>> It reminds me my road_level proposal for some reason.
>>
>> 24.02.2019 17:48 tarihinde djakk djakk yazdı:
>> > ... furthermore, highway_level can be used to classify footway or
>> > cycleway :)
>> >
>> > For example, in a park, some footway are “unclassified” (or
>> > highway_level=5) and some are “primary” (or highway_level=1). Very
>> > useful to render long-range trail.
>> >
>> > djakk
>> >
>> >
>> > Le dim. 24 févr. 2019 à 15:44, djakk djakk > > <mailto:djakk.dj...@gmail.com>> a écrit :
>> >
>> > ... for the unclassified / residential issue : highway_level=5 or
>> > 6 and highway_physics=countryside or town
>> >
>> >
>> > djakk
>> >
>> >
>> Yours, faithfully
>> Erkin Alp
>>
>> ___
>> 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] Clarification unclassified vs residential

[djakk djakk]

Erkin, when did you make this proposal ?

Julien


Le dim. 24 févr. 2019 à 18:31, Erkin Alp Güney  a
écrit :

> It reminds me my road_level proposal for some reason.
>
> 24.02.2019 17:48 tarihinde djakk djakk yazdı:
> > ... furthermore, highway_level can be used to classify footway or
> > cycleway :)
> >
> > For example, in a park, some footway are “unclassified” (or
> > highway_level=5) and some are “primary” (or highway_level=1). Very
> > useful to render long-range trail.
> >
> > djakk
> >
> >
> > Le dim. 24 févr. 2019 à 15:44, djakk djakk  > <mailto:djakk.dj...@gmail.com>> a écrit :
> >
> > ... for the unclassified / residential issue : highway_level=5 or
> > 6 and highway_physics=countryside or town
> >
> >
> > djakk
> >
> >
> Yours, faithfully
> Erkin Alp
>
> ___
> 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] Clarification unclassified vs residential

[djakk djakk]

... furthermore, highway_level can be used to classify footway or cycleway
:)

For example, in a park, some footway are “unclassified” (or
highway_level=5) and some are “primary” (or highway_level=1). Very useful
to render long-range trail.

djakk


Le dim. 24 févr. 2019 à 15:44, djakk djakk  a écrit :

> ... for the unclassified / residential issue : highway_level=5 or 6 and
> highway_physics=countryside or town
>
>
> djakk
>
>
> Le dim. 24 févr. 2019 à 15:25, djakk djakk  a
> écrit :
>
>> Hello !
>>
>> I think we should decorrelate the attributes of a road : its
>> administrative class, its importance in the road network (at least 5
>> levels), its physical characteristics (motorway-like, two large lanes,
>> link=yes ...), possibly its traffic characteristics.
>>
>> So we can tag a secondary motorway or a primary road through a
>> residential area or an official motorway with pedestrians actually walking
>> on it.
>>
>> So that we’ll unify osm road classification through the world (remember
>> the highway=trunk issue ;-))
>>
>>
>> Julien “djakk”
>>
>>
>>
>> Le sam. 23 févr. 2019 à 16:49, Andy Townsend  a
>> écrit :
>>
>>>
>>> On 23/02/2019 15:35, Greg Troxel wrote:
>>> > ... But we don't have
>>> >primary_residential
>>> >primary_not_residential
>>> >
>>> > even though in the US that makes just as much sense as
>>> > level5_residential and level5_not_residential.
>>>
>>> OSM sort-of did have that a very long time ago.  The "abutters" key was
>>> used for something like that (see
>>> https://taginfo.openstreetmap.org/keys/abutters ) but even when I
>>> started (in 2008) I don't remember being told to use that key.
>>>
>>> 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] Clarification unclassified vs residential

[djakk djakk]

... for the unclassified / residential issue : highway_level=5 or 6 and
highway_physics=countryside or town


djakk


Le dim. 24 févr. 2019 à 15:25, djakk djakk  a écrit :

> Hello !
>
> I think we should decorrelate the attributes of a road : its
> administrative class, its importance in the road network (at least 5
> levels), its physical characteristics (motorway-like, two large lanes,
> link=yes ...), possibly its traffic characteristics.
>
> So we can tag a secondary motorway or a primary road through a residential
> area or an official motorway with pedestrians actually walking on it.
>
> So that we’ll unify osm road classification through the world (remember
> the highway=trunk issue ;-))
>
>
> Julien “djakk”
>
>
>
> Le sam. 23 févr. 2019 à 16:49, Andy Townsend  a écrit :
>
>>
>> On 23/02/2019 15:35, Greg Troxel wrote:
>> > ... But we don't have
>> >primary_residential
>> >primary_not_residential
>> >
>> > even though in the US that makes just as much sense as
>> > level5_residential and level5_not_residential.
>>
>> OSM sort-of did have that a very long time ago.  The "abutters" key was
>> used for something like that (see
>> https://taginfo.openstreetmap.org/keys/abutters ) but even when I
>> started (in 2008) I don't remember being told to use that key.
>>
>> 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] Clarification unclassified vs residential

[djakk djakk]

Hello !

I think we should decorrelate the attributes of a road : its administrative
class, its importance in the road network (at least 5 levels), its physical
characteristics (motorway-like, two large lanes, link=yes ...), possibly
its traffic characteristics.

So we can tag a secondary motorway or a primary road through a residential
area or an official motorway with pedestrians actually walking on it.

So that we’ll unify osm road classification through the world (remember the
highway=trunk issue ;-))


Julien “djakk”



Le sam. 23 févr. 2019 à 16:49, Andy Townsend  a écrit :

>
> On 23/02/2019 15:35, Greg Troxel wrote:
> > ... But we don't have
> >primary_residential
> >primary_not_residential
> >
> > even though in the US that makes just as much sense as
> > level5_residential and level5_not_residential.
>
> OSM sort-of did have that a very long time ago.  The "abutters" key was
> used for something like that (see
> https://taginfo.openstreetmap.org/keys/abutters ) but even when I
> started (in 2008) I don't remember being told to use that key.
>
> 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] Link roads between different highways type

[djakk djakk]

Hello !

I think there should be both pieces of information ! A tag to indicate the
main road typology and a tag to indicate the link road typology (basically
the lower class of the interchange but it can be something else in case of
spaghetti junctions).
And let renderers decide which feature they want to use (probably both).

Julien « djakk »


Le mer. 16 janv. 2019 à 14:23, Paul Allen  a écrit :

> On Wed, 16 Jan 2019 at 13:07, Martin Koppenhoefer 
> wrote:
>
> I would argue for motorway links (and trunk links according to the "German
>> trunk interpretation") it is already like this, and for all the other links
>> it could be the other way round. Maybe the rule should be something like
>> the link is the same class than the road it _belongs_ to (and this is to be
>> decided by the mapper, e.g. based on context, road typology, shape, ...).
>> In practise it seems it is done like this.
>>
>
> I would say the rule ought to be that it should be mapped in accordance
> with local laws and
> regulations as to the nature of the link.  If that cannot be determined,
> then the mapper has to use
> best guest based on context, topology, shape, speed limit and other
> signage.  For UK motorways
> the regulations say motorway access roads are classed as motorways and the
> road signage
> confirms it.  That is not necessarily the case for links other than to
> motorways, and possibly not
> even for all of those (there are always exceptions).
>
> I suspect the wiki entry was written in days of yore when a question arose
> about motorway
> access roads and it became enshrined as a general rule for all link roads
> of all types in all
> countries.  Whatever the origin, I think it is time to amend it to
> something more sensible.
>
> --
> 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

[djakk djakk]

Then, why OSM as they are some competent national geographic societies ? ;-)

Julien « djakk »

Le mer. 7 nov. 2018 à 16:19, Mateusz Konieczny  a
écrit :

> 7. Nov 2018 16:15 by djakk.dj...@gmail.com:
>
> Only a independent and crowdsourced database can handle that.
>
>
> Competent public transport company also can do it.
> ___
> 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

[djakk djakk]

 I do not agree with your last argument, it is like « do not add
residential roads before primary roads are all mapped » ;-)

GTFS can have errors (I’ve worked with Paris’ GTFS, bus stops names in caps
locks, sometimes misplaced), plus, as I said, does not reflect the reality
(there was this train from Versailles to Paris scheduled at 8am, always
suppressed for months) (or this bus line 85 from Paris to Saint-Ouen which
very often terminates at the town hall instead of the docks due to delays
due to long term tram construction - this enough regularly to be mapped).
Only a independent and crowdsourced database can handle that.

Julien « djakk »


Le mer. 7 nov. 2018 à 15:34, Paul Allen  a écrit :

> On Wed, Nov 7, 2018 at 2:15 PM OSMDoudou <
> 19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:
>
>> > including the GTFS endpoints and license info as tags, and maybe then
>> adding the ability to discover the GTFS Realtime extension would be the way
>> to go
>>
>> +1
>>
>
> Although I've never used AOL, I have to say "me too."
>
> If a transport company already uses GTFS then they're not going to want to
> bother with duplicating
> the same information in OpenStreetMap.  If they don't already use GTFS
> it's probably because they
> don't want to put in that sort of effort and nobody is forcing them to use
> GTFS, so you have to rely
> on mappers keeping it up to date (timetables in some places are very
> stable and in other places
> subject to change almost upon whim).
>
> It's possible some companies use some method, other than GTFS, with
> license conditions
> that would allow it to be "screen scraped" in which case an auxiliary
> database might be appropriate
> and the tagging scheme that references GTFS could be expanded to include
> this database.  But
> I doubt it would cover more than a handful of cases and may not be worth
> the effort involved.
>
> Worst case, most routes have one or more known operators and we could have
> a tag pointing to
> the operator's web site (better still, the URL of the page showing
> timetables, best of all the URL of
> the timetable for that route alone).  Preferably a key distinct from the
> current website/url keys, although
> I'm open to arguments for re-using them.
>
> And then there are copyright issues.  I can map one the path of variant of
> one bus route by riding the
> bus and breach nobody's copyright.  Timetables, whether taken from a
> website, or a printed timetable
> at a bus stop, open up copyright issues.  Who has the time to ride every
> journey on every route
> several times (to avoid one-off variations giving the wrong time) to
> figure out what the timetable ought
> to be?
>
> Since we have many incomplete/missing/outdated bus routes it seems folly
> to add this extra
> level of detail in this way.  In reality it would deal with a minority of
> the routes we already have
> and would not be adequately maintained, resulting in stale info.
> Incorrect information is worse
> than no information.
>
>
> --
> 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

[djakk djakk]

That is something that OSM should map instead of the official timetable :)

In Paris it is almost the same case, the bus does not follow their official
timetable due to grid locks.

Julien « djakk »


Le mer. 7 nov. 2018 à 00:16, Martin Koppenhoefer  a
écrit :

>
>
> sent from a phone
>
> > On 6. Nov 2018, at 15:41, djakk djakk  wrote:
> >
> > Martin, maybe locals do know their bus stop timetable, as they always
> use the service they may memorize the schedules ... ?
>
>
> there are no timetables and the service is notoriously bad and infrequent,
> while management scandals are frequent. This weekend there will be a
> referendum about closing the public company and procurement by tender.
>
> 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] Public Transport Timetables

[djakk djakk]

For example in Japan transit companies sells their timetable for about
1000€ ... maybe copying the timetable is forbidden but Osm can have at
least an opening hour and a frequency for a line in Japan.
An other example, the city of Accra (Ghana) : only share taxis, no transit
authority, lines are already mapped in OSM, with a travel time and a
frequency.

Julien « djakk »


Le mer. 7 nov. 2018 à 14:37, Jonathon Rossi  a écrit :

> I've been following along the few threads to better understand this topic,
> however I'm still feeling that mapping complex timetables is a bit like
> mapping the full menu of a cafe or restaurant, or the room options at a
> hotel. These things vary whenever the service business chooses and it is
> close to impossible to keep it up to date.
>
> In Brisbane Australia, some PT timetables vary often especially with
> public holidays (local, state or federal), school holidays (which differ
> between schools) and especially with special events (sporting, concerts,
> etc). Sometimes timetables get more trips sometimes less, it can be quite
> variable throughout the year and not something that can be 100% codified
> into timetable rules, and obviously not known too far in advance.
>
> I appreciate that timetables are very useful for consumers of maps, and
> understand that in some cities timetables can be reverse engineered by
> being somewhat observable (I would think copying a full timetable off a
> sign would classify as an import), however are we concerned that this adds
> a massive burden to maintain this data in OSM and it is very likely to
> always be out of date? If it is always going to be out of date will any app
> developer even integrate this data into their app when they can use GTFS
> feeds? The proposal refers to MAPS.ME and OsmAnd, have the developers of
> either application been consulted?
>
> Having this data embedded in the OSM tags also forces apps to reduce their
> map cache duration to try to get more updated timetables.
>
> I'm not very experienced with PT in OSM, but I'd have thought improving
> the tags for mapping objects to GTFS feeds, including the GTFS endpoints
> and license info as tags, and maybe then adding the ability to discover the
> GTFS Realtime extension would be the way to go. I think this would give
> much more power to app developers. It does overlap a little with
> Transitland, but obviously OSM wouldn't be polling or hosting the feeds,
> that would be up to an application developer.
>
> Happy to hear any feedback if I've missed the point of this.
>
> On Tue, Nov 6, 2018 at 2:07 AM Jo  wrote:
>
>> 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
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
> --
> Jono
> ___
> 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

[djakk djakk]

:)

Le mar. 6 nov. 2018 à 20:55, Yves  a écrit :

> Are you looking for a general transit feed specification?
> :)
>
> Yves
>
> Le 6 novembre 2018 20:22:18 GMT+01:00, djakk djakk 
> a écrit :
>>
>> 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

[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 
>>>>>>> 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.
>>>>>>>
>&g

Re: [Tagging] Public Transport Timetables

[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 »
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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. 2

Re: [Tagging] Public Transport Timetables

[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 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
>>>>>>> >:
>>>>>>>
>>&

Re: [Tagging] Public Transport Timetables

[djakk djakk]

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

Re: [Tagging] Public Transport Timetables

[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

[djakk djakk]

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"="> 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 Proposal RFC

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

Re: [Tagging] Public Transport Timetables Proposal RFC

[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

[djakk djakk]

Moreover, timetables in OSM can be useful even incomplete : a mapper can
map only timetables of 2 bus stops, its local bus stop’s and the main stop
of the line (downtown’s bus stop), then you can tell users the timetable
between the bus stops of this suburb and downtown.

Julien « djakk »


Le sam. 3 nov. 2018 à 06:57, djakk djakk  a écrit :

> Yes I trust you ;)
> But where the bus network does not revolutionate (that exists) every 6
> months, timetables and bus stops can be in OSM ...
>
> Julien « djakk »
>
>
> Le sam. 3 nov. 2018 à 06:20, Warin <61sundow...@gmail.com> a écrit :
>
>> On 03/11/18 15:55, djakk djakk wrote:
>>
>> No : bus relations are broken because of the way part, not because of the
>> node part. And detailed timetables will be associated with the nodes.
>>
>> Breaking a bus relation by cutting a street way in half does not implies
>> that the osm timetable breaks too.
>>
>> 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).
>>
>> Mine seem to change every 6 months.
>>
>> Because changing the schedule means buy a new bus and hire new drivers.
>>
>>
>> Not here..some old buses.
>> Occasionally the driver makes a wrong turn .. and asks the passengers
>> where to go. Sometimes that is a new route, sometimes a new driver.
>>
>>
>> Julien « djakk »
>>
>>
>> Le sam. 3 nov. 2018 à 04:48, Joseph Eisenberg 
>> a écrit :
>>
>>> It sounds like we agree: detailed timetables for every bus stop are too
>>> much to maintain, but simple service hours and intervals assigned to a
>>> route are reasonable.
>>>
>>> This would be very useful for map rendering, because an intercity bus
>>> that runs every 10 minutes is quite different than one that run once a day!
>>> On Sat, Nov 3, 2018 at 8:57 AM Graeme Fitzpatrick 
>>> wrote:
>>>
>>>>
>>>> I'm siding with the idea of linking to an external data-base, as
>>>> maintaining this in OSM is going to be a nightmare :-(
>>>>
>>>> On Sat, 3 Nov 2018 at 08:45, Joseph Eisenberg <
>>>> joseph.eisenb...@gmail.com> wrote:
>>>>
>>>>> Sure! But how many GTFS feeds are there in the whole world, compared
>>>>> to the number of towns with public transit?
>>>>>
>>>>> I’m guessing that in Europe perhaps the majority of transit operators
>>>>> publish this info, but it’s not yet universal in they USA, and in Asia and
>>>>> Africa there are 10,000+ cities with no public transit info beyond what is
>>>>> available in OSM
>>>>>
>>>>
>>>> Somebody did mention Moovit earlier: https://moovit.com/
>>>>
>>>> & here is Moovit Indonesia, which may make sense to you but means
>>>> absolutely nothing to me! :-)
>>>>
>>>> https://moovitapp.com/index/in/Tranportasi_Umum-Indonesia
>>>>
>>>>
>>>>> These cities rarely run strict timetables, but the interval (ie
>>>>> headway) between buses and “open_hours) (ie span of service) would be very
>>>>> useful and verifiable info.
>>>>>
>>>>
>>>> In cases like this, when you need to know that the bus to the big city
>>>> should leave on Monday & Thursday mornings, is a bit of a different
>>>> situation to 100s of routes with multiple journeys, & they would be doable.
>>>>
>>>> Thanks
>>>>
>>>> Graeme
>>>> ___
>>>> Tagging mailing list
>>>> Tagging@openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/tagging
>>>>
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>>
>>
>> ___
>> Tagging mailing 
>> listTagging@openstreetmap.orghttps://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

[djakk djakk]

No : bus relations are broken because of the way part, not because of the
node part. And detailed timetables will be associated with the nodes.

Breaking a bus relation by cutting a street way in half does not implies
that the osm timetable breaks too.

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.

Julien « djakk »


Le sam. 3 nov. 2018 à 04:48, Joseph Eisenberg 
a écrit :

> It sounds like we agree: detailed timetables for every bus stop are too
> much to maintain, but simple service hours and intervals assigned to a
> route are reasonable.
>
> This would be very useful for map rendering, because an intercity bus that
> runs every 10 minutes is quite different than one that run once a day!
> On Sat, Nov 3, 2018 at 8:57 AM Graeme Fitzpatrick 
> wrote:
>
>>
>> I'm siding with the idea of linking to an external data-base, as
>> maintaining this in OSM is going to be a nightmare :-(
>>
>> On Sat, 3 Nov 2018 at 08:45, Joseph Eisenberg 
>> wrote:
>>
>>> Sure! But how many GTFS feeds are there in the whole world, compared to
>>> the number of towns with public transit?
>>>
>>> I’m guessing that in Europe perhaps the majority of transit operators
>>> publish this info, but it’s not yet universal in they USA, and in Asia and
>>> Africa there are 10,000+ cities with no public transit info beyond what is
>>> available in OSM
>>>
>>
>> Somebody did mention Moovit earlier: https://moovit.com/
>>
>> & here is Moovit Indonesia, which may make sense to you but means
>> absolutely nothing to me! :-)
>>
>> https://moovitapp.com/index/in/Tranportasi_Umum-Indonesia
>>
>>
>>> These cities rarely run strict timetables, but the interval (ie headway)
>>> between buses and “open_hours) (ie span of service) would be very useful
>>> and verifiable info.
>>>
>>
>> In cases like this, when you need to know that the bus to the big city
>> should leave on Monday & Thursday mornings, is a bit of a different
>> situation to 100s of routes with multiple journeys, & they would be doable.
>>
>> Thanks
>>
>> Graeme
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Public Transport Timetables Proposal RFC

[djakk djakk]

Impossible to maintain ? Maybe but let’s give a try !


djakk


Le ven. 2 nov. 2018 à 08:23, Martin Koppenhoefer  a
écrit :

>
>
> sent from a phone
>
> > On 1. Nov 2018, at 21:19, Roland Olbricht 
> wrote:
> >
> > opening_hours=...
> >for the operation times
>
>
> I’d suggest to use service_times which has the same syntax as opening
> hours but seems semantically more precise.
>
> 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] Public Transport Timetables Proposal RFC

[djakk djakk]

Moreover, GTFS always have some errors, as they are maintained by only a
few people.


djakk


Le mer. 31 oct. 2018 à 10:17, Topographe Fou  a
écrit :

> Hi Leif,
>
> I would rather consider the ability to store a "GTFS API link" (or
> something similar) in transport relations. As soon as its stops are well
> referenced, then an app will have everything it needs with nearly no need
> from users to update them (and ability to automatically detect missing or
> extra stops for QA tools).
>
> Yours
>
> LeTopographeFou
> *De:* 354...@gmail.com
> *Envoyé:* 31 octobre 2018 1:26 AM
> *À:* tagging@openstreetmap.org
> *Répondre à:* tagging@openstreetmap.org
> *Objet:* [Tagging] Public Transport Timetables Proposal RFC
>
> Hello everyone!
> I recently wrote up a proposal page for public transport schedule data.
> This information would allow OpenStreetMap to store information about when
> or how often certain buses or trains arrive at a platform.
>
> https://wiki.osm.org/wiki/Proposed_features/Public_transport_schedules
>
> Please feel free to look over the page and give feedback.  I am very open
> to changing the proposal, so let me know if you have any ideas for
> improvements to it.
> 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

[djakk djakk]

If we allow timetables in OSM, transit companies will possibly maintain
directly them through OSM ;)

There is a lot of non-geographical informations in OSM like the opening
hours of a shop so public transport schedule does not shocked me :)


djakk

Le mer. 31 oct. 2018 à 09:58, Frederik Ramm  a écrit :

> Hi,
>
> On 31.10.2018 00:54, Leif Rasmussen wrote:
> > I recently wrote up a proposal page for public transport schedule data.
> > This information would allow OpenStreetMap to store information about
> > when or how often certain buses or trains arrive at a platform.
>
> Surveying that is hard, and the results only valid for half a year or a
> year at best.
>
> Copying the information may violate a third party's database right, and
> also burdens OSM with dead data that will not be properly maintained.
>
> Therefore I don't think public transport schedules have a place in OSM.
>
> One thing we could investigate is some sort of indication whether a bus
> or train route tagged in OSM is frequent, infrequent, or rarely used -
> but we'd have to find a classifier for this that is vague enough to not
> change twice a year, and precise enough to still be useful (and e.g.
> draw "infrequent" lines with a dashed color on a public transport map or
> so).
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Public Transport Timetables Proposal RFC

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

Most lines of big cities can be map with frequency only (subway every 90
seconds during rush hour, 3 minutes otherwise).


djakk



Le mer. 31 oct. 2018 à 09:02, OSMDoudou <
19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> a écrit :

> As you don't provide more details, this statement reads as a personal
> preference and isn't helping in improving the proposal of enabling public
> transport routing. Can you make a more factual and informative explanation
> as to how it would be bad for OSM to contain timetable data? The proposal
> mentions a number of interesting use cases. Thx.
> ___
> 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] maxspeed:type vs source:maxspeed // StreetComplete

[djakk djakk]

An other example :
http://www.mapillary.com/map/im/k43_fyX2AuL594qhVuSY7w/photo
abutter=residential and highway:legal_type=rural


Le mer. 19 sept. 2018 à 21:41, djakk djakk  a écrit :

> Sound cool but there may be a gap between the reality and the law :
> example : it looks like the countryside but legally it is inside the built
> up area :
> http://www.mapillary.com/map/im/Dybpz_fHGEmWdLjfG7OMvQ/photo
> There should be 2 tags : abutters=rural and highway:legal_type=built_up
>
>
> djakk
>
>
> Le mer. 19 sept. 2018 à 21:27, Tobias Zwick  a écrit :
>
>> Okay, so US-American legislation usually differs between "residential
>> district" and "business district" for maxspeed defaults, as opposed to
>> "built-up area" in most other countries.
>>
>> Actually, there is a tag to denote that a street is in a residential
>> district or business district. It comes from the early days of OSM where
>> people were mapping with their GPS trackers for the lack of available
>> aerial imagery. What about this?:
>>
>> abutters=residential
>> abutters=commercial
>>
>> See https://wiki.openstreetmap.org/wiki/Key:abutters
>>
>> On 19/09/2018 14:08, Greg Troxel wrote:
>> > Tod Fitch  writes:
>> >
>> >>> On Sep 18, 2018, at 6:19 PM, Joseph Eisenberg <
>> joseph.eisenb...@gmail.com> wrote:
>> >>>
>> >>> So on the boundary=administrative admin_level=6 for Rogers County, we
>> could have something like maxspeed:type:default=45mph
>> >>
>> >> Except that more typically there will be different default speed
>> >> limits on each of the various OSM highway classifications. So maybe
>> >> something more like “maxspeed:default:residential=25 mph”.
>> >
>> > I am not aware of *unposted* default limits in the US being different by
>> > an entity smaller than state.   In Massachusetts, there are default
>> > limits in state statutes, in particularly 30 mph in "thickly settled"
>> > areas (also defined in statute).  Some towns have adopted 25 mph in
>> > thickly settled areas, and they have signs at the town borders.
>> >
>> > It's an interesting question at what level to tag individual roads and
>> > when to have some way of expressing rules and therefore to expect all
>> > data consumers to evaluate the rules.  My quick reaction is that
>> > publishing rules for regions smaller than states is going to be too
>> > messy, vs just tagging the ways.
>> >
>> > With respect to maxspeed:default:residential, that's totally unworkable
>> > in Massachusetts.  The law does not talk about roads or even define them
>> > as residential or not.   The question for 30 (vs 40) is whether the road
>> > is "thickly settled", which is
>> >
>> >   built up with structures devoted to business, or the territory
>> >   contiguous to any way where the dwelling houses are situated at such
>> >   distances as will average less than two hundred feet between them for
>> >   a distance of a quarter of a mile or over.
>> >
>> > So there are many roads that are properly tagged "residential" but are
>> > not subject to the lower speed.
>> >
>> > In Mass, we have speed limit tags on almost all legal roads.  To me,
>> > that seems like the most straightforward approach, even if there are
>> > also defaults.
>> >
>> > If the general defaults are intended for routing, that seems more or
>> > less ok.  If they are intended to actually provide speed limit guidance
>> > to drivers, I'm opposed, at least in jurisdictions where they aren't
>> > strictly reliable.
>> >
>> > ___
>> > 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] maxspeed:type vs source:maxspeed // StreetComplete

[djakk djakk]

Sound cool but there may be a gap between the reality and the law : example
: it looks like the countryside but legally it is inside the built up area
:
http://www.mapillary.com/map/im/Dybpz_fHGEmWdLjfG7OMvQ/photo
There should be 2 tags : abutters=rural and highway:legal_type=built_up


djakk


Le mer. 19 sept. 2018 à 21:27, Tobias Zwick  a écrit :

> Okay, so US-American legislation usually differs between "residential
> district" and "business district" for maxspeed defaults, as opposed to
> "built-up area" in most other countries.
>
> Actually, there is a tag to denote that a street is in a residential
> district or business district. It comes from the early days of OSM where
> people were mapping with their GPS trackers for the lack of available
> aerial imagery. What about this?:
>
> abutters=residential
> abutters=commercial
>
> See https://wiki.openstreetmap.org/wiki/Key:abutters
>
> On 19/09/2018 14:08, Greg Troxel wrote:
> > Tod Fitch  writes:
> >
> >>> On Sep 18, 2018, at 6:19 PM, Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
> >>>
> >>> So on the boundary=administrative admin_level=6 for Rogers County, we
> could have something like maxspeed:type:default=45mph
> >>
> >> Except that more typically there will be different default speed
> >> limits on each of the various OSM highway classifications. So maybe
> >> something more like “maxspeed:default:residential=25 mph”.
> >
> > I am not aware of *unposted* default limits in the US being different by
> > an entity smaller than state.   In Massachusetts, there are default
> > limits in state statutes, in particularly 30 mph in "thickly settled"
> > areas (also defined in statute).  Some towns have adopted 25 mph in
> > thickly settled areas, and they have signs at the town borders.
> >
> > It's an interesting question at what level to tag individual roads and
> > when to have some way of expressing rules and therefore to expect all
> > data consumers to evaluate the rules.  My quick reaction is that
> > publishing rules for regions smaller than states is going to be too
> > messy, vs just tagging the ways.
> >
> > With respect to maxspeed:default:residential, that's totally unworkable
> > in Massachusetts.  The law does not talk about roads or even define them
> > as residential or not.   The question for 30 (vs 40) is whether the road
> > is "thickly settled", which is
> >
> >   built up with structures devoted to business, or the territory
> >   contiguous to any way where the dwelling houses are situated at such
> >   distances as will average less than two hundred feet between them for
> >   a distance of a quarter of a mile or over.
> >
> > So there are many roads that are properly tagged "residential" but are
> > not subject to the lower speed.
> >
> > In Mass, we have speed limit tags on almost all legal roads.  To me,
> > that seems like the most straightforward approach, even if there are
> > also defaults.
> >
> > If the general defaults are intended for routing, that seems more or
> > less ok.  If they are intended to actually provide speed limit guidance
> > to drivers, I'm opposed, at least in jurisdictions where they aren't
> > strictly reliable.
> >
> > ___
> > 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] maxspeed:type vs source:maxspeed // StreetComplete

[djakk djakk]

Yes Paul, I should not forget the beginners ...

I am not a beginner anymore but I still found “source:maxspeed=“ for roads
a little confusing, as we should use “source=“ only (?) on the metadata (on
the changeset).

Anyway, for a beginner : is one key even better ? -> should we allow
“maxspeed=no_sign” ? Or/and “maxspeed=default” ?


djakk


Le mer. 19 sept. 2018 à 16:28, Jérôme Seigneuret <
jerome.seigneu...@gmail.com> a écrit :

> Hi, tagging list
> I just join it.
>
> For your information there is part of proposed tagging schema in french
> subject discuss with @djakk.dj...@gmail.com 
>
>
> https://lists.openstreetmap.org/pipermail/talk-fr/2018-September/090189.html
>
> Values of legal type can be thinking in specific territory area and
> resolve "in my opinion" lot of case and subject in relation to access,
> maxspeed, and legal dimension. the last term is "the case" of lot of
> problem of tagging because it can't be appreciated just with maxspeed and
> access definition.
>
> All cases will be deliberate. Speak with law school faculty or a lawyer
> can help us to see all cases.
>
> Jérôme
>
>
> Le mer. 19 sept. 2018 à 15:57, Paul Johnson  a
> écrit :
>
>>
>>
>> On Wed, Sep 19, 2018, 08:27 djakk djakk  wrote:
>>
>>> By the way, we should de-correlate the legal status of an highway from
>>> the highway tag : with the key highway:legal_type, values : business_area
>>> or residential_area or an other local legal classification. A
>>> highway=tertiary could also be highway:legal_type=residential_area
>>>
>>
>> This seems like it would be way less complicated and way easier to
>> troubleshoot and way easier to approach when you're new to the project to
>> just use source:maxspeed=* to explain the context.
>> ___
>> 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] maxspeed:type vs source:maxspeed // StreetComplete

[djakk djakk]

By the way, we should de-correlate the legal status of an highway from the
highway tag : with the key highway:legal_type, values : business_area or
residential_area or an other local legal classification. A highway=tertiary
could also be highway:legal_type=residential_area


djakk



Le mer. 19 sept. 2018 à 14:47, djakk djakk  a écrit :

> Hello !
>
> There is also speed limit areas, a sign is posted at the entrance of the
> area.
>
> Imagine that a big part of Paris becomes a 30km/h area. Is it possible to
> create a big polygon tagged with maxspeed=30, each street inside inherits
> the maxspeed value of the big polygon ? (to escape the inheritance, simply
> tag a segment of street with maxspeed=50 for example)
>
>
> djakk
>
>
>
> Le mer. 19 sept. 2018 à 14:22, Paul Johnson  a
> écrit :
>
>> On Wed, Sep 19, 2018 at 7:18 AM Greg Troxel  wrote:
>>
>>>
>>> Philip Barnes  writes:
>>>
>>> > And if the default actually applies, or has it been overriden by local
>>> signage.
>>> >
>>> > I am not convinced that a default limit helps, if no speed limit has
>>> been surveyed I would prefer that box not to be displayed in my app.
>>> > a. It will not give me wrong and possibly costly information.
>>> > b. It makes it obvious that I should survey and map the limit.
>>> >
>>> > Phil (trigpoint)
>>>
>>> Seconded.  It's actively harmful to display an incorrect limit.
>>> Defaults will inevitably lead to it
>>
>>
>> In practice, this tends to be easy to weed out, as exceptions aren't
>> common (in an overall view of centerline road miles) and quickly dispatched
>> in a short series of surveys or even by armchair if there's OpenStreetCam,
>> Mapillary or Bing Streetside imagery available.
>> ___
>> 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

[djakk djakk]

Hello !

I have in mind my trouble when driving back from Amsterdam toward France. I
knew I had to pass through Lille but I did not see it on the directional
signs. (No gps device back in the days ;-) ) I understood at last close to
the border that the Rijsel I saw all the time on the signs means Lille >_<

Rijsel is not used in France. But it would be very useful to display it on
a map as it it used only several kilometers from the city.


djakk


Le mer. 19 sept. 2018 à 09:57, Jo  a écrit :

> 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 

Re: [Tagging] maxspeed:type vs source:maxspeed // StreetComplete

[djakk djakk]

Hello !

There is also speed limit areas, a sign is posted at the entrance of the
area.

Imagine that a big part of Paris becomes a 30km/h area. Is it possible to
create a big polygon tagged with maxspeed=30, each street inside inherits
the maxspeed value of the big polygon ? (to escape the inheritance, simply
tag a segment of street with maxspeed=50 for example)


djakk



Le mer. 19 sept. 2018 à 14:22, Paul Johnson  a écrit :

> On Wed, Sep 19, 2018 at 7:18 AM Greg Troxel  wrote:
>
>>
>> Philip Barnes  writes:
>>
>> > And if the default actually applies, or has it been overriden by local
>> signage.
>> >
>> > I am not convinced that a default limit helps, if no speed limit has
>> been surveyed I would prefer that box not to be displayed in my app.
>> > a. It will not give me wrong and possibly costly information.
>> > b. It makes it obvious that I should survey and map the limit.
>> >
>> > Phil (trigpoint)
>>
>> Seconded.  It's actively harmful to display an incorrect limit.
>> Defaults will inevitably lead to it
>
>
> In practice, this tends to be easy to weed out, as exceptions aren't
> common (in an overall view of centerline road miles) and quickly dispatched
> in a short series of surveys or even by armchair if there's OpenStreetCam,
> Mapillary or Bing Streetside imagery available.
> ___
> 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] consensus needed: officially a town but visibly distinct settlements?

[djakk djakk]

A renderer can easily pre-compute the nearby places and decides if the
hamlet is isolated or not.

I’ve done that for an European map :
http://itineraires.de.bus.free.fr/carte-des-routes-europeennes-2016/index.html?5,14.4799,61.3229

All the places are rendered (village at least) except there is a bigger
place nearby :)


djakk


On 19 August 2018 at 04:59, Yves  wrote:
>>
>> Who cares if the presence of a post office is the criterum to be a
>> 'village' for a 200 people place if it's the only inhabited place 100km
>> around?
>>
>
> This is a problem we encounter frequently in Australia. The "settlement"
> may consist only of a service station or a pub, plus 1 - 2 houses, so it
> "should" be an OSM hamlet, but it is also the main attraction / centre of
> life (& sometimes the only buildings!) for 300 klm in any direction.
>
> Do you mark it as a hamlet, which will only render at extreme zoom, or
> mark it as a village / town, as it is a vital source of supplies / fuel /
> contact?
>
> Thanks
>
> Graeme.
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] consensus needed: officially a town but visibly distinct settlements?

[djakk djakk]

Place=village and administrative=village or =hamlet ?


djakk


Le sam. 18 août 2018 à 20:50, José G Moya Y.  a écrit :

> Well, from the mapping point of view, these political differences between
> a Spanish small village and a Spanish big hamlet matter:
>
> 1) Villages have their own major, so they have a town hall.
> 2) Villages have their own local rules on max speed, buildings, street
> markets and banking holidays. So a van driver looking to sell his/her
> watermellon cargo could need to know this fact.
>
> El sáb., 18 ago. 2018 20:31, djakk djakk  escribió:
>
>> I agree with Michael, openstreetmap should reflect what the mapers see,
>> not what the politics and the administration see. Though it is also
>> interesting to map administrative things like borders.
>>
>> djakk
>>
>>
>> Le sam. 18 août 2018 à 17:33, Yves  a écrit :
>>
>>> Michael, you don't seem to take the right direction to construct a
>>> fruitful discussion with Jose :)
>>> For your first issue, did you reach the Lithuanian and Russian community?
>>>
>>> Yves
>>>
>>> Le 18 août 2018 16:37:28 GMT+02:00, Michael Tsang  a
>>> écrit :
>>>>
>>>> On Saturday 18 August 2018 22:10:15 HKT José G Moya Y. wrote:
>>>>
>>>>>  Plwase take into notice that, in some countries, the difference between
>>>>>  suburb, hamlet, town or village is not only based on population but in
>>>>>  political issues, such as self-government, also.
>>>>>
>>>>>  When I see my hometown is defined as "aldea" (hamlet) in wikidata I 
>>>>> always
>>>>>  got angry, because, being statistically a hamlet (~200 people), it *is*
>>>>>  politically a *village* (it elects its own town major and has its own 
>>>>> self
>>>>>  government and budget).
>>>>>
>>>>>  There are many such villages in Spain, (specially in the "Spanish 
>>>>> Finland",
>>>>>  the demographic desert between Soria and Teruel) and that is a point of
>>>>>  conflict with many EU directives that request villages provide services a
>>>>>  such small villages can't afford.
>>>>>
>>>>
>>>> But does it look like a village from an untrained eye? i.e. what services 
>>>> does
>>>> it provide? If it really provides services that a village provide than it 
>>>> is
>>>> really a village.
>>>>
>>>> If I am doing the mapping, if the settlement is small (less than 200 
>>>> people)
>>>> AND does not provide services where a village should provide, I will mark 
>>>> it
>>>> as a hamlet despite every official designation.
>>>>
>>>> ___
>>> 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] areas of risk

[djakk djakk]

For such a subjective thing, it should be mapped by each openstreetmap
member : djakk maps this area as dangerous, baloo as not dangerous, etc
 and the renderer makes an average.


djakk



Le sam. 18 août 2018 à 06:26, Paul Johnson  a écrit :

>
>
> On Fri, Aug 17, 2018, 16:17 Adam Franco  wrote:
>
>>
>> Another "risk" case would be an area where a civil war or conflict has
>> divided who controls what land. Either side of the line of control may be
>> incredibly risky for people affiliated with the other side but not to the
>> supporters of those in control.
>>
>
> At least this is objectively reportable and we have tagging for this as a
> result:  Disputed territory is mapped as part of each party state as well
> as disputed=yes on the lines actually under dispute as a basic minimum.
> Though this doesn't tell you if the dispute is, say, a low-simmering
> situation on the level of party states playing professional capture the
> flag (Denmark by way of Greenland vs Canada on Hans Island in the Kennedy
> Strait) or a multilateral bloody humanitarian crisis like Kashmir.
>
>> ___
> 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] consensus needed: officially a town but visibly distinct settlements?

[djakk djakk]

I agree with Michael, openstreetmap should reflect what the mapers see, not
what the politics and the administration see. Though it is also interesting
to map administrative things like borders.

djakk


Le sam. 18 août 2018 à 17:33, Yves  a écrit :

> Michael, you don't seem to take the right direction to construct a
> fruitful discussion with Jose :)
> For your first issue, did you reach the Lithuanian and Russian community?
>
> Yves
>
> Le 18 août 2018 16:37:28 GMT+02:00, Michael Tsang  a
> écrit :
>>
>> On Saturday 18 August 2018 22:10:15 HKT José G Moya Y. wrote:
>>
>>>  Plwase take into notice that, in some countries, the difference between
>>>  suburb, hamlet, town or village is not only based on population but in
>>>  political issues, such as self-government, also.
>>>
>>>  When I see my hometown is defined as "aldea" (hamlet) in wikidata I always
>>>  got angry, because, being statistically a hamlet (~200 people), it *is*
>>>  politically a *village* (it elects its own town major and has its own self
>>>  government and budget).
>>>
>>>  There are many such villages in Spain, (specially in the "Spanish Finland",
>>>  the demographic desert between Soria and Teruel) and that is a point of
>>>  conflict with many EU directives that request villages provide services a
>>>  such small villages can't afford.
>>>
>>
>> But does it look like a village from an untrained eye? i.e. what services 
>> does
>> it provide? If it really provides services that a village provide than it is
>> really a village.
>>
>> If I am doing the mapping, if the settlement is small (less than 200 people)
>> AND does not provide services where a village should provide, I will mark it
>> as a hamlet despite every official designation.
>>
>> ___
> 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] Points instead of areas

[djakk djakk]

For cities there must be a point associated to the polygon to tell where
the center is (maybe 2 if the city is poly centric, like Budapest maybe ?)


djakk

Le mer. 8 août 2018 à 05:25, Warin <61sundow...@gmail.com> a écrit :

> On 08/08/18 12:52, Bill Ricker wrote:
>
>
>
> On Tue, Aug 7, 2018 at 6:41 PM, Graeme Fitzpatrick 
> wrote:
>
>>
>>
>>
>> On 7 August 2018 at 21:56, Daniel Koć  wrote:
>>
>>>
>>> For example nobody would say that a city is a point
>>
>>
>> I'm not disagreeing with you, but people do refer to them, & somehow even
>> measure them, as points!
>>
>> I'm sure that you have the same situation in your country but an e.g. is
>> my State capital, Brisbane: https://en.wikipedia.org/wiki/Brisbane,
>> which
>>
>> covers an area of 15842 km2, but is still apparently found exactly at:
>> ...
>>
>>
> Quite so.
> To measure distances between towns/cities, some point is needed.
> While in theory someone wishing to do so could query for the Admin level
> outline and compute the centroid, when a government entity has declared a
> named point to match the Admin level boundary, it's convenient if everyone
> uses the same one.
> If there are countries which for which open-licensed town centers aren't
> available, the local mapping communities can decide what is right for them.
> Postoffice, Town Hall, Centroid, Flagpole, whatever.
>
>
> The centre of a place is a little cultural, a little of frequent use and a
> little from signs.
> In Europe I suspect it is the railway station ..lots of signs pointing
> there.
> In rural Australia I would go with the post office, though the pub is
> quite popular. :)
> ___
> 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] place nodes for continents?

[djakk djakk]

Why not a big polygon for each continent, subcontinent, ocean, sea ... ?


djakk

Le mar. 7 août 2018 à 12:28, Colin Smale  a écrit :

> As even continents now appear to be subjective, all uses of them should be
> associated with the chosen frame of reference, much like one always
> associates a currency with an amount. A given lump of rock can be in
> multiple continents, each with its own authority, all correct in their own
> ways.
>
>
>
> On 2018-08-07 11:48, Javier Sánchez Portero wrote:
>
> El mar., 7 ago. 2018 a las 10:33, Warin (<61sundow...@gmail.com>)
> escribió:
>
>> But "Officially, there is no centre of Australia." So say the experts.
>> Probably because they cannot reach consensus, sounds familiar :)
>>
>
> We are extending on the "centre" problem, but there aren't even a
> consensus in the number of continents.
>
> https://commons.wikimedia.org/wiki/File:Systemes_de_continents.gif
>
> ___
> 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] Lane geometry in OSM

[djakk djakk]

:-)

Le ven. 3 août 2018 à 17:07, Simon Poole  a écrit :

>
>
> Am 03.08.2018 um 16:30 schrieb djakk djakk:
>
> I think it is less verbose.
>
> That isn't necessarily a positive (just as in programming languages).
>
>
> There can be multiple ways to express something in osm, like in the Ruby
> language ?
>
> While that is certainly the case in OSM, introducing alternative tagging
> just to make things difficult is likely not going to make anybody happy.
>
>
> Simon
>
>
>
> djakk
>
>
> Le ven. 3 août 2018 à 16:21, Marc Gemis  a écrit :
>
>> while this might work, why would you try to replace an established
>> tagging system ?
>> The tagging system turn:lanes:xxx is  supported by several data
>> consumers (OsmAnd, maps.me, MagicEarth and probably others).
>> In many countries people worked on tagging all roads with this system
>> after a project set up by the German community.
>>
>> m.
>> On Fri, Aug 3, 2018 at 4:10 PM djakk djakk  wrote:
>> >
>> > Hello !
>> >
>> > What about a tagging method like this :
>> >
>> > lanes=3
>> > lane_2=forward_direction;left_turn
>> >
>> >  or
>> >
>> > lanes=3
>> > lane_2:direction=forward
>> > lane_2:turn=left
>> >
>> >  instead of
>> >
>> > lanes=3
>> > lanes:forward=2
>> > turn:lanes:forward=left|through
>> >
>> >  ?
>> >
>> >
>> > djakk
>> >
>> >
>> >
>> >
>> >
>> > Le ven. 3 août 2018 à 13:13, Lionel Giard  a
>> écrit :
>> >>
>> >> If you look at the wiki page about different lanes tagging (
>> https://wiki.openstreetmap.org/wiki/Lanes ), you can see that a
>> suggested way of tagging (in "Examples/Motorways") is using letter to
>> indicate which lane goes to where (when there is a transition). This could
>> be used to extent the width tagging for transition lane (where one lane
>> split to two (or conversely). There are already a lot of possibility to tag
>> detailed lanes, but we could indeed add the width in it !
>> >>
>> >> PS: sorry for the previous message, i miss-clicked.
>> >>
>> >> 2018-08-03 13:08 GMT+02:00 Lionel Giard :
>> >>>
>> >>> If you look at the wiki page about different lanes tagging (
>> https://wiki.openstreetmap.org/wiki/Lanes ), you can see that a
>> suggested w
>> >>>
>> >>> 2018-08-02 23:56 GMT+02:00 Tom Hardy :
>> >>>>
>> >>>> I've experimented a bit with lane and road attributes as in
>> >>>> https://www.openstreetmap.org/way/505256201 and the adjoining
>> intersection.
>> >>>> No width, but number, function and placement of lanes.  For
>> placement, I
>> >>>> always selected the center of the throughway.  This allows renderers
>> that pay
>> >>>> no attention to lane attributes to render a straight line through an
>> >>>> intersection.
>> >>>>
>> >>>> JOSM's "Enhanced lane and road attributes" visualizer shows this
>> quite well.
>> >>>>
>> >>>> --
>> >>>> Tom Hardy 
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> ___
>> >>>> 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
>>
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://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] Lane geometry in OSM

[djakk djakk]

I think it is less verbose.

There can be multiple ways to express something in osm, like in the Ruby
language ?


djakk


Le ven. 3 août 2018 à 16:21, Marc Gemis  a écrit :

> while this might work, why would you try to replace an established
> tagging system ?
> The tagging system turn:lanes:xxx is  supported by several data
> consumers (OsmAnd, maps.me, MagicEarth and probably others).
> In many countries people worked on tagging all roads with this system
> after a project set up by the German community.
>
> m.
> On Fri, Aug 3, 2018 at 4:10 PM djakk djakk  wrote:
> >
> > Hello !
> >
> > What about a tagging method like this :
> >
> > lanes=3
> > lane_2=forward_direction;left_turn
> >
> >  or
> >
> > lanes=3
> > lane_2:direction=forward
> > lane_2:turn=left
> >
> >  instead of
> >
> > lanes=3
> > lanes:forward=2
> > turn:lanes:forward=left|through
> >
> >  ?
> >
> >
> > djakk
> >
> >
> >
> >
> >
> > Le ven. 3 août 2018 à 13:13, Lionel Giard  a
> écrit :
> >>
> >> If you look at the wiki page about different lanes tagging (
> https://wiki.openstreetmap.org/wiki/Lanes ), you can see that a suggested
> way of tagging (in "Examples/Motorways") is using letter to indicate which
> lane goes to where (when there is a transition). This could be used to
> extent the width tagging for transition lane (where one lane split to two
> (or conversely). There are already a lot of possibility to tag detailed
> lanes, but we could indeed add the width in it !
> >>
> >> PS: sorry for the previous message, i miss-clicked.
> >>
> >> 2018-08-03 13:08 GMT+02:00 Lionel Giard :
> >>>
> >>> If you look at the wiki page about different lanes tagging (
> https://wiki.openstreetmap.org/wiki/Lanes ), you can see that a suggested
> w
> >>>
> >>> 2018-08-02 23:56 GMT+02:00 Tom Hardy :
> >>>>
> >>>> I've experimented a bit with lane and road attributes as in
> >>>> https://www.openstreetmap.org/way/505256201 and the adjoining
> intersection.
> >>>> No width, but number, function and placement of lanes.  For
> placement, I
> >>>> always selected the center of the throughway.  This allows renderers
> that pay
> >>>> no attention to lane attributes to render a straight line through an
> >>>> intersection.
> >>>>
> >>>> JOSM's "Enhanced lane and road attributes" visualizer shows this
> quite well.
> >>>>
> >>>> --
> >>>> Tom Hardy 
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> ___
> >>>> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Lane geometry in OSM

[djakk djakk]

Hello !

What about a tagging method like this :

lanes=3
lane_2=forward_direction;left_turn

 or

lanes=3
lane_2:direction=forward
lane_2:turn=left

 instead of

lanes=3
lanes:forward=2
turn:lanes:forward=left|through

 ?


djakk





Le ven. 3 août 2018 à 13:13, Lionel Giard  a écrit :

> If you look at the wiki page about different lanes tagging (
> https://wiki.openstreetmap.org/wiki/Lanes ), you can see that a suggested
> way of tagging (in "Examples/Motorways") is using letter to indicate which
> lane goes to where (when there is a transition). This could be used to
> extent the width tagging for transition lane (where one lane split to two
> (or conversely). There are already a lot of possibility to tag detailed
> lanes, but we could indeed add the width in it !
>
> PS: sorry for the previous message, i miss-clicked.
>
> 2018-08-03 13:08 GMT+02:00 Lionel Giard :
>
>> If you look at the wiki page about different lanes tagging (
>> https://wiki.openstreetmap.org/wiki/Lanes ), you can see that a
>> suggested w
>>
>> 2018-08-02 23:56 GMT+02:00 Tom Hardy :
>>
>>> I've experimented a bit with lane and road attributes as in
>>> https://www.openstreetmap.org/way/505256201 and the adjoining
>>> intersection.
>>> No width, but number, function and placement of lanes.  For placement, I
>>> always selected the center of the throughway.  This allows renderers
>>> that pay
>>> no attention to lane attributes to render a straight line through an
>>> intersection.
>>>
>>> JOSM's "Enhanced lane and road attributes" visualizer shows this quite
>>> well.
>>>
>>> --
>>> Tom Hardy 
>>>
>>>
>>>
>>>
>>> ___
>>> 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] Short-term parking zones

[djakk djakk]

Hello Stefan !

I'd make a big polygon :)
I think this has never been used before, but I don't see any problem using
it - except that inheritance of the tags won't be mentioned in the editors


Julien "djakk"

2018-01-13 20:21 GMT+01:00 Stefan Nagy :

> Hi,
>
> in Vienna, Austria parking space management has turned entire districts
> or large connected parts thereof into short-term parking zones (see [1]).
>
> To me it seems that there has to be a better way to map these zones than
> to tag every street therein with the same (sometimes quite complicated)
> parking:condition-tags. And since Vienna isn't the only city with big
> short-term parking zones I wanted to ask for ways how to solve this
> problem.
>
> First I was thinking about implicit parking:condition-values used on all
> streets in these zones, something like
> parking:condition:both=AT:ViennaSTPZx ('x' because right now there are
> three different short-term parking zones in Vienna), in this case I thought
> we could document these implicit values in the wiki. Then on the Austrian
> mailinglist (german thread '[talk-at] Wiener Kurzparkzonen', see [2]) the
> idea
> was brought up that we could use relations with all streets in these zones.
> Maybe type=site relations with parking:condition-tags…?
>
> I hope someone here was confronted with a similar problem before and
> found a good way to map big parking zones.
>
> Thanks,
> Stefan.
>
>
> [1] https://www.wien.gv.at/english/transportation/parking/shortterm.htm
> [2] https://lists.openstreetmap.org/pipermail/talk-at/2018-Janua
> ry/thread.html
>
> --
> E-Mails signieren & verschlüsseln · https://emailselfdefense.fsf.org/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] Nicknames

[djakk djakk]

Good idea !
nick_name=* ? :)


djakk


Le mer. 25 oct. 2017 à 08:09, Daniel Koć  a écrit :

> I think it'd be good to add "Big Apple" nickname as a popular (and
> searchable) kind of placename for a New York:
>
> http://www.openstreetmap.org/node/61785451
>
>
> However nicknames are not defined on the wiki nor used too much as
> "nickname" (just 44 objects):
>
> https://taginfo.openstreetmap.org/keys/nickname
>
>
> The currently stored names (tags without language codes) are:
>
> alt_name=New York City
>
> name=New York
>
> official_name=City of New York
>
> short_name=NYC
>
>
> Should we add "nickname" as another standard naming scheme in wiki
> definition?
>
>
> --
> "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] Toll road sections

[djakk djakk]

Hi Ákos,

I would do this : "toll=hgv_only" and "toll_ref=edid_123456" or
"toll_ref=HU_edid_123456"
(according to the wiki, it should not be toll=hgv_only but : *toll*=no,
*toll*:hgv =yes)

2017-08-28 12:30 GMT+02:00 Topographe Fou :

> I'm not aware of other toll systems but official country references are
> tagged using the prefix ref:XX where XX is the country code. Note that HU
> represent the country and hu the language (see ISO codes). So your prefix
> would be ref:HU.
>
> LeTopographeFou
>
>   Message original
> De: domotor.a...@itineris.hu
> Envoyé: 28 août 2017 11:51 AM
> À: tagging@openstreetmap.org
> Répondre à: tagging@openstreetmap.org
> Objet: [Tagging] Toll road sections
>
> Hi,
>
> The road toll system for HGVs has sections in Hungary. There are appr.
> 2400 of such sections in a varying length from 100 metres to 13 kms.
> We'd like to tag roads with the corresponding toll ID. The base tag
> would be "edid" as the official files use this field name.
> The question is how we should use it. As it's only Hungarian, a "hu:" or
> "hu:ref:" namespace prefix may be appropriate.
> Furthermore, it's only for HGVs so inserting "hgv:" might be sensible as
> well.
>
> Are there any other local toll systems that already use some tagging? We
> could use the same format/logic then.
>
> Greets,
> Ákos
>
> ___
> 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