Re: [Tagging] Feature Proposal - RFC - (consulate)

[Johnparis]

I haven't seen anyone (recently) who supports your original proposal of
keeping amenity=embassy and adding amenity=consulate. So I believe your
first summary is inaccurate.

Instead what I have seen is suggesting that amenity=diplomatic is possibly
a better fit than office=diplomatic.

So I would suggest dropping the first alternative entirely and modifying
the second to read:

* shift to amenity=diplomatic or office=diplomatic (which one to use has
yet to be decided) and use the existing diplomatic=* additional (secondary)
tag to specify whether embassy, consulate, or other, then use embassy,
consulate, and other (or some other euphemism as yet undetermined) as
additional (tertiary) tags to specify further the type of diplomatic or
non-diplomatic mission as needed.

Cheers,

John


On Thu, Nov 1, 2018 at 4:14 AM Allan Mustard  wrote:

> Dear Colleagues,
>
> Eleven days into the RFC, we have three competing lines of thought
> regarding even a primary tag for diplomatic missions, and similarly little
> consensus on additional (secondary  and tertiary) tags that would preserve
> and expand information.  The three lines of thought are:
>
> * retain amenity=* as the primary tag but tag consulates separately from
> embassies (this is the original proposal, which after being criticized
> resurfaced a few days ago).
>
> * shift to office=diplomatic and use the existing diplomatic=* additional
> (secondary) tag to specify whether embassy, consulate, or other, then use
> embassy, consulate and other as additional (tertiary) tags to specify
> further the type of diplomatic or non-diplomatic mission as needed.
>
> * "promote" diplomatic=* to primary tag status, with embassy, consulate,
> and other (or some other euphemism as yet undetermined) as the key values
> as well as additional (secondary) tags that are used to specify further the
> type of diplomatic or non-diplomatic mission as needed.
>
> Nearly all the discussion is posted to the talk page of Proposed
> Features/Consulate in the wiki ,
> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Consulate for
> those interested in reviewing it.
>
> Now, as we approach the two-week mark, it would be helpful to get a sense
> of whether there is any consensus out there about which of the three main
> lines of thought is preferred over the others.  The preferences of the
> community responding to this RFC are not clear to me.  Please let me know
> which direction you believe would be best, bearing in mind both the
> realities of the OSM universe (relative sophistication of mappers, the
> desire not to burden unduly renderers of maps, and the degree to which
> anybody reads the wiki articles) and our shared desire to make OSM as
> accurate and information-rich as possible.  Which of the above approaches
> do you think is "best" by those criteria?
>
> Very best regards to one and all who have contributed to this discussion,
> and many thanks for your ideas and expressions of concern.
>
> apm-wa
> ___
> 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] Feature Proposal - RFC - (consulate)

[Allan Mustard]

Dear Colleagues,

Eleven days into the RFC, we have three competing lines of thought
regarding even a primary tag for diplomatic missions, and similarly little
consensus on additional (secondary  and tertiary) tags that would preserve
and expand information.  The three lines of thought are:

* retain amenity=* as the primary tag but tag consulates separately from
embassies (this is the original proposal, which after being criticized
resurfaced a few days ago).

* shift to office=diplomatic and use the existing diplomatic=* additional
(secondary) tag to specify whether embassy, consulate, or other, then use
embassy, consulate and other as additional (tertiary) tags to specify
further the type of diplomatic or non-diplomatic mission as needed.

* "promote" diplomatic=* to primary tag status, with embassy, consulate,
and other (or some other euphemism as yet undetermined) as the key values
as well as additional (secondary) tags that are used to specify further the
type of diplomatic or non-diplomatic mission as needed.

Nearly all the discussion is posted to the talk page of Proposed
Features/Consulate in the wiki ,
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Consulate for
those interested in reviewing it.

Now, as we approach the two-week mark, it would be helpful to get a sense
of whether there is any consensus out there about which of the three main
lines of thought is preferred over the others.  The preferences of the
community responding to this RFC are not clear to me.  Please let me know
which direction you believe would be best, bearing in mind both the
realities of the OSM universe (relative sophistication of mappers, the
desire not to burden unduly renderers of maps, and the degree to which
anybody reads the wiki articles) and our shared desire to make OSM as
accurate and information-rich as possible.  Which of the above approaches
do you think is "best" by those criteria?

Very best regards to one and all who have contributed to this discussion,
and many thanks for your ideas and expressions of concern.

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

Re: [Tagging] Public Transport Timetables Proposal RFC

[Michael Patrick]

 Globally, US DOT, the World Bank, ASFAIK all EU countries, have settled on
GTFS, or eventually will on some future version.

So there are two cases:
1. Transit Services that use GTFS
2. Transit Services that do not use GTFS

For Case 1, the General Transit Feed Specification Reference declares that
the geographical elements ( which correspond to OSM geometry types ) are to
be declared and maintained on the GTFS side, and since OSM doesn't have any
sort of permanent / persistent element ID to bind that fact, the robust
technical solution especially for complex transit system would be a
automated CRUD
 refresh of
the geometry. You're still at the mercy of OSM side latency to some extent,
but doable.

OSM would be useful in Case 2, to initially provide the geometries to a
GTFS feed not maintained by an agency - it is simply a set of .txt files,
this has been done for small local routes on GitHub. Then the technical
solution above applies. Ongoing, maintain your GTFS feed to whatever level
you feel suffices. And you could publish your feed to the registry, to
everyone's benefit.

( ... this is overly simplistic, and invokes the ball of snakes of opinions
and philosophies on automated imports, so your pretty much back to some
sort of parallel OSM implementation with the main OSM as essentially a
background layer. ).

BTW, Google Transit ( or any of the others ) do not store the data, they
rely of the GTFS feed.

Michael




Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Public Transport Timetables Proposal RFC

[Leif Rasmussen]

Graeme Fitzpatrick:
I have changed the proposal, and the level of detail that you describe can
now be added very easily.  At the bus stop, the proposal now states to
create one new relation for each bus route stopping at that stop and
include both the stop and the route inside each of those new relations.
Then, add the tag departures=* to mark the timetable.
See this example: https://www.osm.org/relation/8873463

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

Re: [Tagging] Public Transport Timetables Proposal RFC

[Tijmen Stam]

> Thanks for the feedback on this proposal!  Maintainability and corruption
> of existing features seem to be the two biggest concerns, both of which I
> have reduced in the new version of the proposal.  I really like the idea
> that Polyglot expressed on the talk page of the proposal of using a
> completely separate relation to represent a single timetable.  It is a
> completely different system that is much more elegant, versatile,
> practical, and simple.  By using a relation similar in design to turn
> restrictions, the complexity of this proposal has been reduced
> significantly.
>
> The new version of the proposal will not affect existing public transport
> routes in any way or form.  They will remain unchanged and uncorrupted,
> similarly to how turn restrictions do not affect highways in any
> noticeable
> way.  Data consumers will not have to worry about any changes to public
> transport details.
>
> https://wiki.osm.org/wiki/Proposed_features/Public_transport_schedules

As others, I strongly oppose having public transport timetables in OS

Maintainability and doubling of data are the main problems. Any data
consumer that could do something with this, could just as well source
their data from a GTFS or similar feed. I heard one commenter say he/she
hoped PT companies would add their data to OSM - I think they far earlier
would invest into having their data automatically exported into GTFS (or
another open data format, such as BISON in the Netherlands)

Another drawback is that many lines would very quickly hit the
256-character value limit. I work in public transit, and many of "my"
lines have 50 trips per direction per day (but 220 is no exception) all
leaving at slightly different minutes of the hour and having slightly
different travel times. Things aren't so simple anymore that we have a
peak, off-peak and evening/sunday service pattern, and I think you grossly
underestimate the complexity of PT timetabling.

In my view, Openstreetmap is a geographical database and in my view this
is too far from geographical data to be a valuable OSM addition.

I see one exception where timetables could be useful and valuable
addition: anywhere where a "portage" function exists, where another mode
piggybacks on a timetabled transport: Cars on ferries or train shuttles,
bicycles on public elevators, walkers on funiculars etc.

These usually have a very predictable route and timetable structure
(exceptions off course apply)
•between two nodes without intermediate stops
•Fixed start and finish times based on day and period of year
(=opening_hours, may be different per direction)
•Fixed going tmes (e.g. :20 from point a, :50 from b) ór fixed headways
(every 15 minutes)
•Very predictable transit times (e.g. always 20 minutes)
•Usually quite distinct in their use and operation from "traditional"
public transit like buses or ferries

In this way, a data consumer can make a prediction of say, an ETA of a
route that uses a ferry with tags that are not much more complicated than
an opening_hours tag.

Just my 2 cents,
Tijmen/IIVQ


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

Re: [Tagging] Public Transport Timetables Proposal RFC

[seirra]

this does feel like a much easier to understand idea now, it may be 
worth thinking of a way to still incorporate the interval in the second 
proposed feature, for example a local bus in my area has one every 10 
minutes for a substantial amount of time.



On 10/31/18 21:04, Leif Rasmussen wrote:
Thanks for the feedback on this proposal! Maintainability and 
corruption of existing features seem to be the two biggest concerns, 
both of which I have reduced in the new version of the proposal.  I 
really like the idea that Polyglot expressed on the talk page of the 
proposal of using a completely separate relation to represent a single 
timetable.  It is a completely different system that is much more 
elegant, versatile, practical, and simple.  By using a relation 
similar in design to turn restrictions, the complexity of this 
proposal has been reduced significantly.


The new version of the proposal will not affect existing public 
transport routes in any way or form.  They will remain unchanged and 
uncorrupted, similarly to how turn restrictions do not affect highways 
in any noticeable way.  Data consumers will not have to worry about 
any changes to public transport details.


https://wiki.osm.org/wiki/Proposed_features/Public_transport_schedules

Please let me know what you all think about the improved proposal.  
Maintainability will still be difficult, but much easier than before.  
It may also be possible for these types of relations to be added by, 
and checked for currency by, StreetComplete without much trouble.


Example of a timetable relation: 
https://www.openstreetmap.org/relation/8873463


Thank you,
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

[Leif Rasmussen]

Thanks for the feedback on this proposal!  Maintainability and corruption
of existing features seem to be the two biggest concerns, both of which I
have reduced in the new version of the proposal.  I really like the idea
that Polyglot expressed on the talk page of the proposal of using a
completely separate relation to represent a single timetable.  It is a
completely different system that is much more elegant, versatile,
practical, and simple.  By using a relation similar in design to turn
restrictions, the complexity of this proposal has been reduced
significantly.

The new version of the proposal will not affect existing public transport
routes in any way or form.  They will remain unchanged and uncorrupted,
similarly to how turn restrictions do not affect highways in any noticeable
way.  Data consumers will not have to worry about any changes to public
transport details.

https://wiki.osm.org/wiki/Proposed_features/Public_transport_schedules

Please let me know what you all think about the improved proposal.
Maintainability will still be difficult, but much easier than before.  It
may also be possible for these types of relations to be added by, and
checked for currency by, StreetComplete without much trouble.

Example of a timetable relation:
https://www.openstreetmap.org/relation/8873463

Thank you,
Leif Rasmussen
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Public Transport Timetables Proposal RFC

[Graeme Fitzpatrick]

As others have said, it could be handy but probably better just linked to
an external data-base.

One concern I have is trying to insert a schedule for different routes that
use the same stop?

eg This bus stop has a 53 bus about every 30 minutes from 7am till 5pm; a
65 bus every 10 minutes in peak time & 20 minutes outside 24 hours a day; a
77 bus every hour, from 6 till 6; a school bus at 8am; & a long-distance /
interstate coach twice a day. (& that's not a made up example! - it's a
single bus stop near us, but I've actually simplified the details a bit :-))

How would you insert that level of detail?

Thanks

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

Re: [Tagging] Feature Proposal - RFC - landuse=governmental

[SelfishSeahorse]

On Wed, 31 Oct 2018 at 12:00, Martin Koppenhoefer
 wrote:
>
> WRT to Joseph's comment about "municipal, statal and federal", I would 
> welcome adding a property for the level (if a generic level is chosen for 
> landuse), maybe "admin_level" would suit best?

This seems like a good idea.

> How will we deal with uses shared by bodies of different levels in the 
> hierarchy, e.g. a site which is used together by federal and state entities 
> (e.g. on different building levels, or in cooperation).

I think it should be save to add all admin_level's separated by semicolons.

Regards
Markus

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

Re: [Tagging] Public Transport Timetables Proposal RFC

[Dave F]

Hi

I hope you're open to rescinding this proposal.

This data is too transient to be of benefit within the OSM database. The 
poor implemented & negligibly maintenance of opening hours is a good 
example as to why it shouldn't be added.


The numerous Public Transport schemas are a mess. Their problems need 
sorting out, not adding to. From what I've seen, most of PT's tags are 
duplicates of other which are already established & work well. See 
'public_transport=station'


'stop_areas' are a pig's ear of incomprehensibility. Even those who 
conceived it appear uncertain as to its scope.


Cheers
DaveF


On 30/10/2018 23:54, Leif Rasmussen wrote:

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

[Allan Mustard]

That’s true even in parts of the developed world.  It would be useful!

Sent from my iPhone

> On Oct 31, 2018, at 4:18 PM, Joseph Eisenberg  
> wrote:
> 
> I agree that it would be useful and reasonable to have frequency (headway’s) 
> and the days a route is served.
> 
> Here in Indonesia, most local buses do not run on a timetable, but it would 
> be very useful to know if there is one bus a day, one per hour, or one per 
> minute. This makes a huge difference, and can be verified without needing to 
> copy an official timetable, if you know the local routes.
> 
> Even back in the USA it would be useful and reasonably maintainable to record 
> the frequency of transit vehicles at different times. Something like “Mo-Fr 
> every 30m 5:30-7:00; 10m 7:00-9:00; 15m 9:00 to 15:00; 10m 15:00 to 18:00; 
> 30m 18:00 to 22:00” 
> 
> This gets you most of the information you need to make a good public transit 
> map, because you can have more frequent routes render with wider lines or 
> brighter colors. And it even provides enough info for approximate route 
> planning.
> 
> In developing countries this would probably be the highest level of detail 
> available. There are no GTFS databases for most of the non-Western world, so 
> it would be useful.
> 
> Joseph
>> On Wed, Oct 31, 2018 at 7:04 PM Michael Reichert  
>> wrote:
>> TL;DR I am agains this proposal. Timetables in OSM are an ugly hack.
>> Please store them outside of OSM and link them using foreign keys.
>> 
>> 
>> Hi Leif,
>> 
>> Am 31.10.18 um 00:54 schrieb Leif Rasmussen:
>> > 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
>> 
>> I think that the frequency and the days a route is served is sufficient.
>> There should not be any more details about the timetable in OSM beyond
>> that. While public transport looks simple :-) if you look at urban
>> areas, it becomes difficult to model if you go to the boundary of urban
>> areas or even into rural areas or developing countries.
>> 
>> OSM already struggles to model route relations for bus lines which have
>> 15 trips per day but 12 different variants (e.g. bus lines in rural
>> Germany). How do you deal with train lines which run on days matching
>> the following specification only?
>> 
>> > nur Fr, So
>> > auch 22.XII., 26.XII., 27.XII., 1.I., 2.I., 28.II., 6.III., 14.II.,
>> > 18.IV., 22.IV., 30.IV., 1.V., 2.V., 29.V., 30.V., 11.VI., 2.X., 30.X.
>> > nicht 21.IV., 31.V., 1.VI., 9.VI., 21.VI., 4.X.
>> >
>> > Fr = Friday
>> > So = Sunday
>> > nur … = on … only
>> > auch … = also on …
>> > nicht … = not on …
>> 
>> This specification changes every year and it can't be simplified to "Fr,
>> Su and public holidays in at least two German states". Currently, many
>> route relations don't have to be modified every year but your tagging
>> schema would force mappers to do so. And the example above is quite
>> simple. In practice, the specification is even longer because many
>> constructions to refurbish the railway network a running and lead to
>> different departures nearly every second weekend or trains don't serve
>> the whole line from start to end because parts of the line are closed on
>> some weekends/weeks during the year due to constructions.
>> 
>> How would you deal with lines which have a clear interval of 60 minutes
>> if you round all depatures and arrival times? There are a lot of train
>> lines where the times differ by a +-3 minutes through the day. Peak vs.
>> off-peak is not the reason.
>> 
>> OSM was designed to be a database for geometries with attributes. The
>> database design of OSM has some issues but I am sure that database
>> designed for public transport timetables would not require the timetable
>> to be encoded into relation membership roles and relation tags.
>> 
>> Using OSM to encode timetables looks more like a ugly hack and should be
>> solved by having some kind of foreign key as tag of the route relation
>> which is used by a separate database project under a free and open
>> license which is designed for and used to store timetable information.
>> 
>> Nobody forbids anyone to run a project for crowdsourced timetable
>> information. But it is out of scope for OSM.
>> 
>> Your tagging proposal suggests to use relation membership roles to store
>> depatures in a way like that:
>> "platform:Mo-Fr 08:40, 09:40, 10:40, 11:40, 12:40, 13:40, 14:40, 15:40,
>> 16:40, 17:10, 17:40, 18:10, 18:40, 19:40, 20:40"
>> 
>> Aren't membership roles limited to 256 characters, too?
>> 
>> In addition, your tagging schema is incompatible with the current public
>> transport tagging schema and probably all recently discussed proposals
>> which aim to replace or improve it. All of them know a role "platform".
>> From my point of view, relation membersh

Re: [Tagging] Public Transport Timetables Proposal RFC

[Joseph Eisenberg]

I agree that it would be useful and reasonable to have frequency
(headway’s) and the days a route is served.

Here in Indonesia, most local buses do not run on a timetable, but it would
be very useful to know if there is one bus a day, one per hour, or one per
minute. This makes a huge difference, and can be verified without needing
to copy an official timetable, if you know the local routes.

Even back in the USA it would be useful and reasonably maintainable to
record the frequency of transit vehicles at different times. Something like
“Mo-Fr every 30m 5:30-7:00; 10m 7:00-9:00; 15m 9:00 to 15:00; 10m 15:00 to
18:00; 30m 18:00 to 22:00”

This gets you most of the information you need to make a good public
transit map, because you can have more frequent routes render with wider
lines or brighter colors. And it even provides enough info for approximate
route planning.

In developing countries this would probably be the highest level of detail
available. There are no GTFS databases for most of the non-Western world,
so it would be useful.

Joseph
On Wed, Oct 31, 2018 at 7:04 PM Michael Reichert 
wrote:

> TL;DR I am agains this proposal. Timetables in OSM are an ugly hack.
> Please store them outside of OSM and link them using foreign keys.
>
>
> Hi Leif,
>
> Am 31.10.18 um 00:54 schrieb Leif Rasmussen:
> > 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
>
> I think that the frequency and the days a route is served is sufficient.
> There should not be any more details about the timetable in OSM beyond
> that. While public transport looks simple :-) if you look at urban
> areas, it becomes difficult to model if you go to the boundary of urban
> areas or even into rural areas or developing countries.
>
> OSM already struggles to model route relations for bus lines which have
> 15 trips per day but 12 different variants (e.g. bus lines in rural
> Germany). How do you deal with train lines which run on days matching
> the following specification only?
>
> > nur Fr, So
> > auch 22.XII., 26.XII., 27.XII., 1.I., 2.I., 28.II., 6.III., 14.II.,
> > 18.IV., 22.IV., 30.IV., 1.V., 2.V., 29.V., 30.V., 11.VI., 2.X., 30.X.
> > nicht 21.IV., 31.V., 1.VI., 9.VI., 21.VI., 4.X.
> >
> > Fr = Friday
> > So = Sunday
> > nur … = on … only
> > auch … = also on …
> > nicht … = not on …
>
> This specification changes every year and it can't be simplified to "Fr,
> Su and public holidays in at least two German states". Currently, many
> route relations don't have to be modified every year but your tagging
> schema would force mappers to do so. And the example above is quite
> simple. In practice, the specification is even longer because many
> constructions to refurbish the railway network a running and lead to
> different departures nearly every second weekend or trains don't serve
> the whole line from start to end because parts of the line are closed on
> some weekends/weeks during the year due to constructions.
>
> How would you deal with lines which have a clear interval of 60 minutes
> if you round all depatures and arrival times? There are a lot of train
> lines where the times differ by a +-3 minutes through the day. Peak vs.
> off-peak is not the reason.
>
> OSM was designed to be a database for geometries with attributes. The
> database design of OSM has some issues but I am sure that database
> designed for public transport timetables would not require the timetable
> to be encoded into relation membership roles and relation tags.
>
> Using OSM to encode timetables looks more like a ugly hack and should be
> solved by having some kind of foreign key as tag of the route relation
> which is used by a separate database project under a free and open
> license which is designed for and used to store timetable information.
>
> Nobody forbids anyone to run a project for crowdsourced timetable
> information. But it is out of scope for OSM.
>
> Your tagging proposal suggests to use relation membership roles to store
> depatures in a way like that:
> "platform:Mo-Fr 08:40, 09:40, 10:40, 11:40, 12:40, 13:40, 14:40, 15:40,
> 16:40, 17:10, 17:40, 18:10, 18:40, 19:40, 20:40"
>
> Aren't membership roles limited to 256 characters, too?
>
> In addition, your tagging schema is incompatible with the current public
> transport tagging schema and probably all recently discussed proposals
> which aim to replace or improve it. All of them know a role "platform".
> From my point of view, relation membership roles are keys. Keys should
> not contain value information.
>
> Best regards
>
> Michael
>
>
> --
> Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
> ausgenommen)
> I prefer GPG encryption of emails. (does not apply on mailing lists)
>
>
> ___

Re: [Tagging] Feature Proposal - RFC - landuse=governmental

[Martin Koppenhoefer]

Am Mi., 31. Okt. 2018 um 11:49 Uhr schrieb SelfishSeahorse <
selfishseaho...@gmail.com>:

> I think if editors will name the landuse=governmental preset
> 'government premises', there won't be a high risk that people would
> use this tag for land owned or regulated by the government.
> Alternatively, renaming the tag landuse=government_premises (or
> landuse=governmental_site) should clear up any ambiguities.




We should be very clear about whether the land is owned by the public, or
used by the public. Landuse is a property for the current use, so
landuse=governmental (or whatever is chosen) should indicate used by the
government. This could be private property (and rented), or public property.

WRT to Joseph's comment about "municipal, statal and federal", I would
welcome adding a property for the level (if a generic level is chosen for
landuse), maybe "admin_level" would suit best?

How will we deal with uses shared by bodies of different levels in the
hierarchy, e.g. a site which is used together by federal and state entities
(e.g. on different building levels, or in cooperation).

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

Re: [Tagging] Feature Proposal - RFC - landuse=governmental

[SelfishSeahorse]

On Sun, 14 Oct 2018 at 04:02, Joseph Eisenberg
 wrote:
>
> However, I'm not sure that "governmental" is the best value for the landuse 
> key. I think there would be a risk of mappers finding this tag in the editors 
> and using it for all governnment-owned land, not just for administrative 
> offices. In North America, and in many developing countries, the national or 
> local government owns large areas of land, including rangeland, forests, 
> transportation facilities, and military areas, in addition to land uses for 
> government offices.
>
> In North America, it is somewhat common to talk about "government land" or 
> more specifically, "Federal land," "State land", and "Municipal land". But 
> the only uses of "governmental land use" I've found are in phrases talking 
> about "governmental land use policy", "governmental land use regulations", 
> and "governmental land use decision making". In these cases, the phrase is 
> talking about governments regulating all types of land use, including 
> commercial, retail, residential and industrial.

I think if editors will name the landuse=governmental preset
'government premises', there won't be a high risk that people would
use this tag for land owned or regulated by the government.
Alternatively, renaming the tag landuse=government_premises (or
landuse=governmental_site) should clear up any ambiguities.

Regards
Markus

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

Re: [Tagging] Public Transport Timetables Proposal RFC

[Michael Reichert]

TL;DR I am agains this proposal. Timetables in OSM are an ugly hack.
Please store them outside of OSM and link them using foreign keys.


Hi Leif,

Am 31.10.18 um 00:54 schrieb Leif Rasmussen:
> 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

I think that the frequency and the days a route is served is sufficient.
There should not be any more details about the timetable in OSM beyond
that. While public transport looks simple :-) if you look at urban
areas, it becomes difficult to model if you go to the boundary of urban
areas or even into rural areas or developing countries.

OSM already struggles to model route relations for bus lines which have
15 trips per day but 12 different variants (e.g. bus lines in rural
Germany). How do you deal with train lines which run on days matching
the following specification only?

> nur Fr, So
> auch 22.XII., 26.XII., 27.XII., 1.I., 2.I., 28.II., 6.III., 14.II.,
> 18.IV., 22.IV., 30.IV., 1.V., 2.V., 29.V., 30.V., 11.VI., 2.X., 30.X.
> nicht 21.IV., 31.V., 1.VI., 9.VI., 21.VI., 4.X.
>
> Fr = Friday
> So = Sunday
> nur … = on … only
> auch … = also on …
> nicht … = not on …

This specification changes every year and it can't be simplified to "Fr,
Su and public holidays in at least two German states". Currently, many
route relations don't have to be modified every year but your tagging
schema would force mappers to do so. And the example above is quite
simple. In practice, the specification is even longer because many
constructions to refurbish the railway network a running and lead to
different departures nearly every second weekend or trains don't serve
the whole line from start to end because parts of the line are closed on
some weekends/weeks during the year due to constructions.

How would you deal with lines which have a clear interval of 60 minutes
if you round all depatures and arrival times? There are a lot of train
lines where the times differ by a +-3 minutes through the day. Peak vs.
off-peak is not the reason.

OSM was designed to be a database for geometries with attributes. The
database design of OSM has some issues but I am sure that database
designed for public transport timetables would not require the timetable
to be encoded into relation membership roles and relation tags.

Using OSM to encode timetables looks more like a ugly hack and should be
solved by having some kind of foreign key as tag of the route relation
which is used by a separate database project under a free and open
license which is designed for and used to store timetable information.

Nobody forbids anyone to run a project for crowdsourced timetable
information. But it is out of scope for OSM.

Your tagging proposal suggests to use relation membership roles to store
depatures in a way like that:
"platform:Mo-Fr 08:40, 09:40, 10:40, 11:40, 12:40, 13:40, 14:40, 15:40,
16:40, 17:10, 17:40, 18:10, 18:40, 19:40, 20:40"

Aren't membership roles limited to 256 characters, too?

In addition, your tagging schema is incompatible with the current public
transport tagging schema and probably all recently discussed proposals
which aim to replace or improve it. All of them know a role "platform".
From my point of view, relation membership roles are keys. Keys should
not contain value information.

Best regards

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)




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

[Dave Swarthout]

I went ahead and did it the way I described in my last post. Clumsy but it
worked. I've been busy conflating coastline and riverbanks with the
boundary, throwing away thousands of unnecessary nodes in the process. I
like cleaning house like that but it's a ton of work that most people don't
do.

I like your ideas, Kevin, and will try them when I do my next big addition.
Removing the outer ring is a clever approach. I have separated all the
National Wildlife Refuge shapefiles into their own folders so it's no
biggie if I "wreck" one to isolate the inners. I selected my inners after
doing the Paste at Source Location step by searching in JOSM for "type:way
untagged new" as I described earlier but I did not unselect the nodes as
you recommend. Is that necessary and if so, why?

I tried another thing in my experimenting with those selections. There is a
button in the middle panel of Relation Editor that Selects objects. It's
the second from the bottom and the mouseover hint says:  "Select objects
for selected relation members".  In the leftmost panel I selected all the
inners from the shapefile relation in the shapefile layer (click on
topmost, [Shift] click on the last), clicked that button which moved them
to the right-hand pane and when I exited the Relation Editor those objects
appeared in JOSM's "Selection" panel. I cannot remember now if I was able
to copy and use them in my data layer but that button is interesting. Do
you or anyone else know how to use it?

Dave

PS: I live in fear of "losing the selection" LOL. Every time I tried to
transfer these blasted inners I lost the selection, which is why I resorted
to the JOSM search.



On Tue, Oct 30, 2018 at 7:47 PM Kevin Kenny  wrote:

> On Tue, Oct 30, 2018 at 7:54 AM Dave Swarthout 
> wrote:
>
>> Someone added the Arctic National Wildlife Refuge to OSM but did not add
>> a bunch of inner areas that aren't part of the refuge. I have the inners in
>> a shapefile that end up in a separate layer when I import them into JOSM. I
>> would like to add those inners to the existing boundary of the refuge. How
>> can I transfer those inners from the shape layer to my data layer?
>>
>> I've tried everything I can think of, including the special paste
>> function inside the Relation Toolbox I learned about recently, but cannot
>> get them to transfer *en masse*. I can copy and paste them one at a time
>> but there are a few dozen tiny parcels. I also tried pasting them in place
>> and then using JOSM's Search function to select "type:way untagged new" and
>> that worked but it's clumsy.
>> There must be a better way to do this.
>>
>
> If you have just the one multipolygon in the shapefile, or you have just
> the inners in the shapefile, it's pretty easy.
>
> Import the shapefile into JOSM. Yes, it comes in as a new layer.
>
> Select the inner rings by whatever means.  One possibility is to delete
> the outer ring (just don't save the shapefile again, or save it under a new
> name before you start so that you can throw it away) and then 'Select All'
> followed by 'Select->Unselect Nodes' (Shift+U). Copy the inner ways
> (Ctrl+C).
>
> Switch to the OSM layer and do Ctrl+Alt+V (Paste at Source Location).
>
> You now have your newly pasted items selected. Bring up the relation
> editor on your relation, and you'll see the selected items in the
> right-hand column. Use the 'insert at the bottom' button in the middle bar
> to bring them over. into the relation.
>
> Now they're in the left-hand column, and still selected.  Type 'inner' in
> the 'role' prompt at the bottom and hit the check mark. Now they're all
> inner ways.
>
> If you're afraid of losing the selection, add some tag like 'dave=1' to
> the items before you copy-n-paste, and then the Search dialog can find them
> easily. (Don't forget to delete the tag when you're done!)
>
>
>

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

Re: [Tagging] Public Transport Timetables Proposal RFC

[Topographe Fou]

  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).YoursLeTopographeFou   De: 354...@gmail.comEnvoyé: 31 octobre 2018 1:26 AMÀ: tagging@openstreetmap.orgRépondre à: tagging@openstreetmap.orgObjet: [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_schedulesPlease 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

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Martin Koppenhoefer]

Am Mi., 31. Okt. 2018 um 02:41 Uhr schrieb Allan Mustard :

> Nobody wants to be called "minor" in diplomacy.  Wars have been fought
> over lesser insults.  If that's the only other suggestion, then my proposal
> will remain "other" :-o
>
The head of the OSCE mission here in Ashgabat is a former ambassador and
> will certainly take umbrage with me if her mission is somehow described as
> "minor".
>


I agree that minor may not be a good term if we want everybody to embrace
the tag. In my opinion, "other" is not acceptable as a key for something as
specific as the subtype of diplomatic missions which aren't either
embassies nor consulates. It is far too broad. "other_mission" would come
close to "other" but would give some indication on the context (maybe there
remains some ambiguity, because "mission" is used in different context too).



> if these are all exclusive, it could also be:
>>
>> amenity=[embassy, consulate, minor_mission]
>>
> I think we are past the point of calling diplomatic missions "amenity".
> We're now down to either "office=diplomatic" or "diplomatic=*"  There has
> been broad consensus expressed that diplomatic missions are not amenities.
>


While I still don't see a problem with amenity (the key is currently a home
for monasteries, churches, temples, mosques, hospitals, schools,
pharmacies, post offices, grave yards, pubs, police stations, townhalls,
community_centres, social_facilities, dentists, marketplaces, bus stations,
theatres, universities, courthouses, banks, embassies, prisons...), I could
live with office=diplomatic as well, while introducing a new main tag would
probably lead to disruption and would be a good way to ensure that
amenity=embassy never goes away (which it maybe won't anyway, people will
likely add additional tags and retain the amenity=embassy tag).

Cheers,
Martin
___
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

[Frederik Ramm]

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

Re: [Tagging] Public Transport Timetables Proposal RFC

[Jo]

Op wo 31 okt. 2018 om 09:31 schreef djakk djakk :

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

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

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

Re: [Tagging] Public Transport Timetables Proposal RFC

[Volker Schmidt]

It is generally a bad idea to store data twice in different places. Any
database expert will agree with that.
It's a simple question of data maintanance.
OSM is being suffocated with imports/insertion of data that are maintained
outside OSM, and hence needs regular re-import or manual update:
buildings, landuse, monumental trees, publc transport routes, whatever, and
now even time tables of public transpiort.
How on earth can we maintain all that stuff in a single data base with our
manpower?
And as we cannot maintain our data copies in OSM, they will drift apart
from the originals from the moment they are imported/inserted. No
reasonable person would trust public transport timetables that are in OSM.

My five Eurocents.

Volker





On Wed, 31 Oct 2018 at 09:02, OSMDoudou <
19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:

> 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] 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] Public Transport Timetables Proposal RFC

[OSMDoudou]

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

Re: [Tagging] Feature Proposal - RFC - (consulate)

[Allan Mustard]

Sounds like you just volunteered to do a session on tagging at the next SOTM 
and to help me write the wiki articles supporting whatever we end up voting on 
:-)

I hear you on tagging but don’t agree that a current inadequacy of tagging is a 
reason to torpedo improvement to accuracy and clarity.

The vast majority of users will not care if it is a consulate or consulate 
general. They will want the location so they know where to go to apply for a 
visa or a passport. Let’s not be hypnotized by the complexity—simple top-level 
choices for simple mappers that can be expanded with additional tags by more 
experienced mappers.  It will make rendering easier snd the database more 
accurate.  That is my objective here.



Sent from my iPhone

> On Oct 31, 2018, at 9:45 AM, Warin <61sundow...@gmail.com> wrote:
> 
>> On 31/10/18 12:33, Allan Mustard wrote:
>> Some responses to Warin:
>> 
>>> On 10/31/2018 3:45 AM, Warin wrote:
>>> Errr.
>>> By combining Embassy with High Commission there is a decrease in 
>>> information.
>>> 
>> No information is lost.  "High Commission" is an embassy by another name, 
>> between Commonwealth members.  The term "high commission" would be preserved 
>> both in the embassy=* tag and the name=* tag.
> Mappers don't do sub tags well
> Example;
> Over 11,000 amenity=embassy
> Some 4,000 diplomatic=* 
> 
> Less than half the 'embassies' have the tag diplomatic, yet over 95% have a 
> name tag. 
> So they will use the name tag (that renders) together with the 
> amenity=embassy tag (that renders) but they are reluctant to use the 
> diplomatic tag (that does not render).
> 
> I think the same will occur to these embassy=* tags.
> 
> Another decrease in information is consulate and consult general ... there 
> may be more if I dig. 
>>> The VCDR does not mention embassy. It has 'mission' and 'consular' but no 
>>> 'embassy', nor 'high commission' etc.
>>> 
>> As I pointed out in an earlier post, "embassy" technically and legally 
>> consists of the people dispatched to a foreign country on a diplomatic 
>> mission.  By convention and in vernacular use, "embassy" is used to denote 
>> the physical structure of the diplomatic mission in which said people 
>> operate.  The VCDR is a legal document (a treaty).  It uses legal language.  
>> I have provided a great deal of detail (much of which would be captured in 
>> the wiki, ultimately) describing the various flavors of diplomatic missions, 
>> which broadly speaking fall into three categories: embassies, consulates, 
>> and other.  If you doubt my word, as you seem to, please consult with your 
>> local ministry of foreign affairs.  If you are willing to take the word of 
>> Wikipedia, its article on diplomatic missions is pretty good: 
>> https://en.wikipedia.org/wiki/Diplomatic_mission#Naming
 Then the real fun begins.  As I have read through the various comments and 
 suggestions, it has occurred to me that the following hierarchy of tags 
 would potentially fill the bill:
 The three values/categories (embassy, consulate, other) would have 
 specific subcategories.  If you wanted to do a key search in overpass 
 turbo, it would still be possible. The subcategories would be 
 
 * embassy=[embassy/yes, nunciature, high_commission, interests_section, 
 mission, delegation, branch_embassy]
 
 * consulate=[consulate/yes, consulate_general, consular_agency, 
 consular_office, honorary_con
 
>>> The above 'consolidations' ... loose information.
>>> 
>> How do they lose information?  All information is preserved in the 
>> additional tags.
> Those additional tags probably won't be used, see above. 
>>> If required that consolidation can be done in rendering. 
>>> 
>>> But, I think, most renders now ignore them and simply render all of them 
>>> the same. And, I think, that will continue for quite some time. 
>>> 
>>> If a render chose to distinguish between them then they can do so, they 
>>> cannot distinguish between an embassy and a high commission if that 
>>> information is not there.
>>> 
>> I cannot conceive of a circumstance under which anyone would want to render 
>> embassies and high commissions differently.  They are different names for 
>> the same level of diplomatic mission (a mission covered by the VCDR and 
>> headed by an ambassador).  If a renderer wanted to distinguish them, it 
>> could be done with an IF statement testing the existence of the string 
>> "high_commission" in either the name=* tag or the embassy=* tag.  Same goes 
>> for an overpass turbo search.
> 
> If there no difference then they would be the same name. 
> Could be construed as the same kind of thing as the tag 'minor_mission'.  :) 
> 
> Embassies and consulate are now rendered the same, that will probably 
> continue, even if they have different tags. 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/taggi

Re: [Tagging] Public Transport Timetables Proposal RFC

[OSMDoudou]

A couple of thoughts:

- The schedules I know have values different for week days and week-ends and again for school holidays, so I wonder if the depature tag value (as well as the other timetable tags) of frequent departure lines will not run into the 255 character limit. This is similar to the opening_hours tag which was discussed recently [1]. This possible issue should be looked into: based on real data: how likely is it to happen, and how can the tagging scheme circumvent the limit?

- As the proposal mentions, there exist public and maintained sources of data (GTFS). Can you discuss how this proposal will not result on the long run in duplicating these data, thus requiring double maintenance? Wouldn't it be better to interface and integrate this external data (like with wikimedia tag)?

[1] https://lists.openstreetmap.org/pipermail/tagging/2018-October/039889.html



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

Re: [Tagging] Public Transport Timetables Proposal RFC

[Tom Pfeifer]

I am strongly against storing timetable data in OSM.

tom

On 31.10.2018 00:54, Leif Rasmussen wrote:

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