[Talk-transit] [Spam] Re: [Talk-gb-westmidlands] NaPTAN data import

Gerrit Lammert osm at 00l.de
Sat Mar 7 13:46:14 GMT 2009

Hi Peter.

Peter Miller wrote:
> On 6 Mar 2009, at 21:16, Gerrit Lammert wrote:
> 1) We are aware that there is not consistency between transport modes
> within OSM and that is confusing. For example it is railway=station and
> aeroway=station but it is amenity=bus_station. Places where people wait
> for transport are nodes within the highway for some modes (railway/tram)
> but beside the road normally for others (buses).

Exactly. This should be unified and made consistent.

> We need to sort this out carefully but need to get it right. Note that
> the phase 'halt', being proposed as the tag for where a vehicles stops
> on the highway is actually already used in OSM, as in 'railway=halt' for
> "A small station, may not have a platform, trains may only stop on
> request. ".

It is not proposed as the tag where vehicles stop on the highway. That
would be highway=bus_stop.
It is however the abstract term I use for what you call "stop point"
within the proposal.
It is also the "stop point" for railway vehicles. Here I actually
propose a slightly changed meaning from your cited "small station" to
"one 'stop point' of potentially many in a railway station of any size.
The reason is, that this way all smaller railway stations are compatible
with the new model, nothing has to be removed or retagged.

> So... OSM could decide to work it out for itself as it goes along with
> its own modelling concepts and terminology and that might be interesting
> and sort of fun in parts. But that approach does run into all of the
> above potential problems when connecting with other projects.
> I propose that we determine to migrate towards Transmodel terms and
> modelling concepts over time and where we need to introduce new elements
> we use their terms and modelling concepts for preference. I know that
> the terms are sometimes a bit nerdy and arbitrary but we do know that
> they are tested, self-consistent, respected and work for many many
> applications. Our terms would probably also be pretty arbitrary.

I agree that we should avoid inventing something that has already been
But (and it's a capital "But"), the most important thing is to make it
What you wrote about the Transmodel-creation is what I fear. There you
have a lot of people that know their way around PT develop a model that
covers all their needs.
In OSM you have a thousand times their numbers and most of them have no
clue (and only little interest) in PT.
On this List, most of you seem to professionally work with PTV on an
every day basis. Please keep in mind that the users of the to be
proposed OSM-Model are not!
I see only three ways this might go:
1) everything stays at it is -> enough for 95% of the mappers, but
rather unusable for more complex usage scenarios
2) have the fully blown professional transmodel (or whatever) model
adopted into OSM -> mappers won't/can't use it -> all data comes from
outside databases like administrative entities or PT companys. Exact
data, but we would be dependent on these.
3) have a basic model that suffices 95% of the mappers and 95% of the
usage scenarios, allow it to be optionally extended (not replaced) by
more complex data and stuff

Of course, number 3 would be the only feasible solution in my opinion.

> I propose that we create a 'Proposed Transmodel Migration' page to work
> up what we would need to change to achieve this - based on the unified
> stop area page, but with a new name. This proposal would then be put to
> a vote when it is complete, there would not be an assumption that it
> would happen until we saw how it worked out.

I oppose.
This should be approached from the OSM side of things with transmodel
and others in mind. It should NOT be the primary goal to have it all
made transmodel-like but merely transmodel-compatible.

> I also propose that we treat this project as separate from the NaPTAN
> import. Let's get on with that and then over the next month work up the
> 'unified modelling' conversion, get agreement for it and then do a
> conversion to the new format in a controlled way.

I agree. Will you start a new wiki for that?
I'm not familiar with transmodel, I would be interested in the main
ideas and data structures behind it, so we could try and mimic those in
the OSM model where manageable and sensible.



More information about the Talk-transit mailing list