Re: [Talk-transit] Relations for stop areas in NaPTAN

[Claudius Henrichs]

Am 28.09.2009 15:05, Peter Miller:


On 28 Sep 2009, at 13:44, Jerry Clough - OSM wrote:

I've just noticed that the relations for stop places generated in the 
NaPTAN import do not have a type. I just happened to be browsing 
through some KeepRight issues and noticed a number of relation 
without type ones.


I'm sure its unimportant right now, but I wondered how the stop 
place/stop area/interchange ideas are firming up, and what I should 
do eventually with the NaPTAN data.


I noticed yesterday that the public transport article[1]  is still 
linking to 'User:Oxomoa/Public transport schema' article for tagging 
information even though this is a personal page and therefore not 
something that others should touch.


For starters should we agree not to link to personal pages for tagging 
information?


I have developed a Stop Area article[2] based on Oxomoa's proposal and 
which also included feedback from CEN. It is currently available as a 
'proposed feature'. however it should in general echo current 
practice. Would it be appropriate to now move it into the main 
name-space and use it as the primary overview article for stations, 
bus stops etc?


If so should we just do it or do a formal vote first. Given that it is 
actually now a summary of current practice I would recommend moving it 
without voting but would be happy to follow the majority view. 
Thoughts please!


[1] http://wiki.openstreetmap.org/wiki/Public_Transport
[2] http://wiki.openstreetmap.org/wiki/Proposed_features/Stop_Area


Regards,

Peter

As a late-joiner to this list I definitely vote for moving Oxomoa's 
proposal to the "public" wiki space.


Could anyone give a quick comment on what the consensus of the list 
member's on using his proposal is? I've been using it extensively and 
find it to be well though through and suitable for almost every possible 
public transport layout and on the same time offering the best 
possibility to have as much information covered in OSM as possible.


Claudius
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Relations for stop areas in NaPTAN

[Claudius Henrichs]

Am 28.09.2009 17:10, Frankie Roberto:


2009/9/28 Thomas Wood >


I think the type=* tag on relations is ugly, similar to the original
class=* tag proposed on every element in the early days of OSM.

class=* was dropped, as should type=* be.


I don't know too much about class=, but I can see an argument that 
type= might be redundant on relations. However, given that it is in 
such widespread use, I guess this is a bigger debate to have.


Right now, I'm more concerned about which of these patterns is better:

type=site
site=railway_station

or

type=site
railway=station

The first one has the advantage of following the X=Y, Y=Z tag 
hierarchy convention, the second has the advantage of re-using tags 
that have long been adopted for nodes.


Frankie


Why not simply:

public_transport=stop_area_group

etc as proposed in Oxomoa's proposal?
Fixing the JOSM validator to allow "public_transport" instead of "type" 
is an easy task.


Claudius
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Relations for stop areas in NaPTAN

[Claudius Henrichs]

Am 28.09.2009 17:24, Cartinus:
> On Monday 28 September 2009 17:13:21 Claudius Henrichs wrote:
>
>> Could anyone give a quick comment on what the consensus of the list
>> member's on using his proposal is? I've been using it extensively and
>> find it to be well though through
>>  
> I'm still opposed to replacing route with line just for public transport. That
> part was definitely not well thought out.
>
So it's only the naming that you don't like? Could be that "line" is 
more appealing to german mappers :P I could go with route=bus as well. 
But the tagging scheme of the line/route relation is okay to you as well?

Claudius

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] JOSM Plugin

[Claudius Henrichs]

Am 05.02.2010 15:36, Roland Olbricht:
> Hello,
>
> as I consider mapping bus services as quite intricate, I've written a plugin
> for JOSM to make editing for comfortable. It is not very mature so far, but I
> would be grateful for any bug reports, comments and suggestions:
>
> The plugin itself
> http://78.46.81.38/misc/public_transport.jar
> And some documentation
> http://78.46.81.38/misc/public_transport.readme.txt
>
> The idea behind that is to standardise the data representation, according to
> http://wiki.openstreetmap.org/wiki/User:Oxomoa/Public_transport_schema
>
> The plugin has successfully been used to map several bus lines in Wuppertal,
> in particular
> http://www.openstreetmap.org/browse/relation/163298
> http://www.openstreetmap.org/browse/relation/359774
> http://www.openstreetmap.org/browse/relation/34633
> http://www.openstreetmap.org/browse/relation/359796
>
> The source code is available at
> http://78.46.81.38/misc/public_transport.tar.gz
> I have not figured out so far how to add this plugin to the JOSM SVN.
>
Cool. So far I've seen a new menu item "Public transport" having 
appearing in my main menu. Anything else to discover?

If you were asking for a wishlist: Double-click routes or stops should 
actually select the relation/node and center the editor's view on the 
latter. What's the "Tags"-tab used for? It's empty when I loaded my 
Leipzig public transport data.

I haven't discovered yet how the "Suggest stops" feature works.

Thanks again for this plugin. Looks very promising,
Clauidus

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] RFC on interchanging data

[Claudius Henrichs]

Hello Roland,
you hit the nail on the head: public_transport:stop_area relations are the 
way to go. At least I keep mapping stations/stops with interchange 
possibilities like that. Please do not forget about stop_area_group as well 
as these relations are used to denote interchanging possibilites between 
nearby stop_areas :)

Claudius

> 
>  Original-Nachricht 
> Datum: Wed, 24 Feb 2010 18:09:52 +0100
> Von: Roland Olbricht 
> An: "Public transport/transit/shared taxi related topics" 
> 
> Betreff: [Talk-transit] RFC on interchanging data
> 
> Hello everybody,
> 
> What is the consensus on how to map interchange data? I would like 
> connect two 
> (or more) bus stops and/or railway stations to indicate that you can 
> preferably change vehicles there (e.g. the bus stop(s) that is/are 
> intended to 
> change into a nearby train station). This is often indicated by sharing 
> the 
> same name, but not always.
> 
> I haven't found anything useful about this neither on
> http://wiki.openstreetmap.org/wiki/Public_Transport
> and its connected pages nor on
> http://wiki.openstreetmap.org/wiki/User:Oxomoa/Public_transport_schema
> and I want to know which data model (or models) I hard-code into my 
> software 
> and use for the data I map.
> 
> I think that membership within a relation "public_transport=stop_area" 
> fits 
> best for this purpose but I'm not sure whether I can interpret all 
> existing 
> stop areas in this way. Thus, I would be grateful for any comments.
> 
> Cheers,
> 
> Roland
> 
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit
> 

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] RFC on tram stops

[Claudius Henrichs]

Hello Roland,

My first reply would be:
public_transport=stop_position/platform
tram=yes

If you want to keep backward compatibility definitely go for 
railway=tram_stop because trams are considered part of the railway network. 
I've never heard about nor seen any actually tagged as highway=tram_stop. I 
only know highway=bus_stop.

Claudius

> 
>  Original-Nachricht 
> Datum: Wed, 24 Feb 2010 18:14:22 +0100
> Von: Roland Olbricht 
> An: "Public transport/transit/shared taxi related topics" 
> 
> Betreff: [Talk-transit] RFC on tram stops
> 
> Hello everybody,
> 
> What is the consensus on how to map tram stops? I've found 
> "highway=tram_stop" 
> as well as "railway_tram_stop". The wiki page
> http://wiki.openstreetmap.org/wiki/Trams
> says nothing about that.
> 
> Cheers,
> 
> Roland
> 
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit
> 

-- 
Sicherer, schneller und einfacher. Die aktuellen Internet-Browser -
jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] OSM Transit platform: call for action

[Claudius Henrichs]

Am 28.06.2010 17:37, Michał Borsuk:



On 28 June 2010 14:14, Tiziano D'Angelo > wrote:


Hello everybody!

In the past months, as you probably read here, I mapped almost
entirely the bus network of Padova, Italy. 



Abstract: A new standard, better suited but compatible with what has 
been done is needed.



Hi! I have also mapped almost my entire area, and I have found that 
the option of combining OSM with bus timetables is not presently 
feasible. There are the following problems:


* missing important details.  Just like you did, I skipped some 
strange variants such as special Sunday early morning runs, or 
collective taxis (because they tend to go wherever the people want). 
Also, there is at present no provision for implementing the "time" of 
bus lines, so at present one could be advised to take a night line at 
daytime.
I think the first step is getting hold if unique station identifiers. 
You would need to check if something like that exsists for your country 
or at least transport association. From than on it's quite easy to go 
forward. See http://wiki.openstreetmap.org/wiki/Naptan
* no approved standard. Should the stops be within the line as a 
point, or as their physical location shows? Should we map a separate 
relation just for the branch of the line from the split, or for the 
entire line? What is the point of having two relations for two 
directions in Europe? IMHO Oxomoa seems way too difficult for 
beginners, and it's overblown. The overhead needed to maintain the 
standard is WAY too big. I have calculated that sticking to the 
standard would cost me 25 to 50% more time, with just marginally 
better results. The time to understand the standard is also not to be 
ignored. A new standard, better suited but compatible with what has 
been done is needed.
Just a comment on the complexity of the public transport scheme by 
Oxomoa: You could get along with a very basic variant already and thus 
be standard-conform:
- Just put all way segments and the stop_positions in a relation with 
"from=..." and "to=..."
- Clone the relation in JOSM and reverse the order and switch "from=..." 
and "to..."

- put those two relations in a "line=bus/tram" relation  and you're done.
Not much more effort. In later expansions you might add the 
public_transport=platform and stuff


The wiki article is indeed very long, but as a starter it can be 
reduced to the above :)


Claudius
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Proposed changes to oxomoa schema [part 1]

[Claudius Henrichs]

Please find my comment on core lines below.

Am 28.06.2010 19:54, Michał Borsuk:

--

*ISSUE RAISED:
* change to the way more complex lines are mapped, that is the 
introduction of tags or roles instead of nested collections*


Present status: For lines with variants, each variant needs a separate 
relation


Problems:
* Nested relations are difficult to impossible to manage in potlatch,
* They are difficult to understand
* Creating a variant requires the entire route to be duplicated:  
impossible in potlatch

* Extending or rerouting such lines can be hell
* High risk of introducing a mess by inexperienced users (I think). I 
actually think my proposal is more error-resistant.
* It's time-consuming! It's easy to duplicate a line once one knows 
JOSM, but how much time does it take to get JOSM running, from 
downloading to having results? A lot.


*Proposed change: introduction of a "core line", that is shared by all 
variants in all directions, and having the branches or exceptions in 
one direction tagged appropriately. Core line would have no tags, 
branch lines would be tagged arbitrarily. *


Result: lower consistency of the data entered, but much less time 
needed to enter and manage lines. The "mess" can be easily dealt with 
by server-side software presenting data to users. If one wants a route 
from one's side branch of a line, one looks down the tagged branch up 
to the main branch, and then up to the stop needed. Nothing hard to 
implement. It's the 21st century, I believe that we don't have to rely 
on simple parsers that take nothing else but point-to-point connections.
How would you enter this core line? It would be a relation with the ways 
and stops of the course again. So you would need the core line be a 
member of the branches and exception relations again. Probably I haven't 
fully understood how you would see your core lines respresented in the 
OSM data model.


Pozdrowienia,
Claudius
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Proposed changes to oxomoa schema [part 2: stops]

[Claudius Henrichs]

Oxomoa is suggesting bus stop on the way only for the most basic bus 
stop (think of a bus stop on a crossing on the country side with just a 
sign). If you have a more advanced bus stop with waiting positions for 
passengers on both sides of the street you add a 
public_transport=stop_position on the way *and* add a 
public_transport=platform node/way on the location you are proposing 
(e.g. "where they are"). This solution allows to fulfill the data 
requirements of routers you described.

More details in the graphics here:
http://wiki.openstreetmap.org/wiki/User:Oxomoa/Public_transport_schema#Examples_for_the_application_of_the_model_for_stops

Claudius

Am 28.06.2010 20:07, Michał Borsuk:

*ISSUE RAISED:
* map bus stops to their physical location, not a point on the 
route/street

*
Present status: If I understand correctly, oxomoa suggests that the 
bus stop data (name, unique number, etc.) be entered as properties of 
a point on the route/street.


Problems :
* Lines often have stops that are quite far apart for each direction
* This prohibits proper routing (GPS + walking),
* this system is not very intuitive I find.

*Proposed change: bus stops to be mapped exactly to where they are, 
and to be added to relations *


Result:
* better routing results e.g. one wants to find a correct way to the 
bus stop, and not to the average point somewhere between two stops of 
the same name in either direction.

* more intuitive system -> easier "learning curve" for new users.

Influence on possible future software solutions: minor. May require 
all the stops on the route to be ordered based on their geographical 
location, as opposed to their place on the route (the latter is easier).


Comments: I have seen this system very often implemented - two bus 
stops on each side, so my suggestion is just to codify the situation 
for future editors.


Hope this is not too much at once, for more is to follow.


Greetings,


--
Best regards, mit freundlichen Grüssen, meilleurs sentiments, 
Pozdrowienia,


Michał Borsuk


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit
   


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Proposed changes to oxomoa schema [part 2: stops]

[Claudius Henrichs]

Am 28.06.2010 22:16, Michał Borsuk:


More details in the graphics here:

http://wiki.openstreetmap.org/wiki/User:Oxomoa/Public_transport_schema#Examples_for_the_application_of_the_model_for_stops


The link you provided is a very good example of oxomoa's weakness. 
While the first simple bus stop is clear, for two bus stops I must 
"create a stop_area". How do you do that? (the example is not clear 
enough) And more importantly, what for? Is the gain worth the extra 
time, which is considerable?
Most of the time a relation for public_transport=stop_area is not 
necessary e.g. if you have two crossing bus lines which have the same 
name. In this case the router can easily determine that there's a 
changing location.
But if you have more infrastructure like a taxi stand (See here: 
http://www.openstreetmap.org/browse/relation/152809 ) or a ferry 
terminal it's sometimes necessary to create a stop_area. But no need to 
worry: Don't do it if you think it's too much time. Eventually someone 
else does it. In OSM you don't have to do everything yourself. And you 
don't need to do the whole 1000km² yourself :)


Do you have a map link to the area you are mapping public transport 
data? Maybe a complex example which took you time to tag?


Claudius
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

[Talk-transit] Naptan import stop tagging (was: Proposed changes to oxomoa schema [part 2: stops])

[Claudius Henrichs]

One question on the Naptan import: Did you use any tags from the 
public_transport therefore? Or are these all highway=bus_stop?
Would be a great chance to increase coverage of the more detailed 
public_transport=platform

Claudius

Am 29.06.2010 02:07, Shaun McDonald:
In the UK as part of the Naptan import we already have decided that 
bus stops must be marked exactly where they are on the ground and 
added to the route relation of the bus route.


Shaun

On 28 Jun 2010, at 19:07, Michał Borsuk wrote:


Hi everybody again:

This time I'd like to propose a smaller change, but this one may 
break compatibility with oxomoa - it has been, however, already 
commonly implemented.


*ISSUE RAISED:
* map bus stops to their physical location, not a point on the 
route/street

*
Present status: If I understand correctly, oxomoa suggests that the 
bus stop data (name, unique number, etc.) be entered as properties of 
a point on the route/street.


Problems :
* Lines often have stops that are quite far apart for each direction
* This prohibits proper routing (GPS + walking),
* this system is not very intuitive I find.

*Proposed change: bus stops to be mapped exactly to where they are, 
and to be added to relations *


Result:
* better routing results e.g. one wants to find a correct way to the 
bus stop, and not to the average point somewhere between two stops of 
the same name in either direction.

* more intuitive system -> easier "learning curve" for new users.

Influence on possible future software solutions: minor. May require 
all the stops on the route to be ordered based on their geographical 
location, as opposed to their place on the route (the latter is easier).


Comments: I have seen this system very often implemented - two bus 
stops on each side, so my suggestion is just to codify the situation 
for future editors.


Hope this is not too much at once, for more is to follow.


Greetings,


--
Best regards, mit freundlichen Grüssen, meilleurs sentiments, 
Pozdrowienia,


Michał Borsuk
___
Talk-transit mailing list
Talk-transit@openstreetmap.org 
http://lists.openstreetmap.org/listinfo/talk-transit



___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit
   


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Proposed changes to oxomoa schema [part 2: stops]

[Claudius Henrichs]

Am 29.06.2010 10:22, Michał Borsuk:

On 29.06.2010 09:33, Tiziano D'Angelo wrote:

+1

On Tue, Jun 29, 2010 at 08:23, Arun Ganesh > wrote:


Shouldn't we keep the schema to something that is easily
compatible with the Google Transit GTFS format instead of
developing something different all together?


Doesn't GTFSsuggest one location for one unique stop name, whereas we 
want each physical location belonging to a name as a separate point? 
(this does not suggest incompatibility, just an overlay on GTFS)


LMB

GTFS covers Oxomoa's extended form of tagging a stop area as well:
stops.txt contains an optional location_type where the value "1" would 
represent a public_transport=stop_area:
0 or blank - Stop. A location where passengers board or disembark from a 
transit vehicle.

1 - Station. A physical structure or area that contains one or more stop.

In most cases the stop positions in both directions will have different 
locations and thus different stop_lat and stop_lon in GTFS as well. So 
we are already "easily compatible".


Claudius
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Naptan import stop tagging

[Claudius Henrichs]

I was referring to

public_transport=platform + bus=yes

public_transport=bus_stop would not work because there are stop 
positions where trams, buses and sometimes (Karlsruhe comes to my mind) 
even light_rails stop at the same position (Image: 
http://www.dvn-berlin.de/i/verein/2009_alex_bus_hpa.jpg ) and these 
would be tagged as


public_transport=platform + bus=yes + tram=yes (+ light_rail=yes)

Claudius

Am 29.06.2010 11:32, Richard Mann:

They're all still highway=bus_stop. I think I'd need some convincing
that public_transport=platform was appropriate for bus stops.
Public_transport=bus_stop, maybe.

Why change?

Richard

On Tue, Jun 29, 2010 at 9:59 AM, Claudius Henrichs  wrote:
   

One question on the Naptan import: Did you use any tags from the
public_transport therefore? Or are these all highway=bus_stop?
Would be a great chance to increase coverage of the more detailed
public_transport=platform
Claudius
 


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Claudius Henrichs]

Am 11.01.2011 08:03, Michał Borsuk:



On 11 January 2011 07:24, Dominik Mahrer (Teddy) > wrote:


Hi all

One month ago I already posted an RFC on this proposal. In the
meantime I got plenty of comments and I have
extended/corrected/rewritten nearly the whole proposal.

Please visit again
http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport


This:

* The route-Relation
   is split
  up into two separate *direction*-Relation
  s and
  separate route *variants*, if required.
* The *route master*-Relation
   contains
  all the relations for the route directions and variants

...is a copy of oxomoa, which has been criticized as overbloated. Why 
was it kept in the new draft? What are the arguments for two relations 
in each direction?
I don't feel it to be bloated instead it's necessary, needed and 
practically in use. And especially for the "simple" or new mapper it 
seems way easier to create two relations for each direction than messing 
with forward/backward roles.

Arguments for relations in each direction:
- easier to check correctness and completeness (simply select each 
direction's relation in JOSM)
- easier to manage routes where the vehicle takes different routes and 
stops in each direction

...
I already see it's more a question of taste here, but I feel it's more 
elegant to work with seperated relations for each direction. And less 
stressfull when using a 300 members opposed to a 500+ member relation.
From a short test it seems like P2 does work fine with nested relations 
so that's no counter-argument anymore.


The type=route_master thingie is new to me, but I prefer it over Oxomoa 
which recycled route=line for the master and it's members and thus mixed 
the two levels.


I strongly support this proposal which 90% reflect how I'm currently 
mapping in Europe and Asia.

Claudius
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Claudius Henrichs]

Am 11.01.2011 07:24, Dominik Mahrer (Teddy):

Hi all

One month ago I already posted an RFC on this proposal. In the 
meantime I got plenty of comments and I have 
extended/corrected/rewritten nearly the whole proposal.


Please visit again
http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport

Regards
Teddych
You should add on top of the examples one of the most basic "out on the 
countryside" bus stops that does not require a stop_area relation as 
they probably reflect at least half of all bus stops worldwide. 
Currently it looks like you need a public_transport=stop_area-relation 
everywhere


Claudius

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Public transport proposal

[Claudius Henrichs]

Am 13.01.2011 13:27, Richard Fairhurst:

Hello all,

I note with some alarm the very complex, relation-heavy proposal for 
mapping simple public transport objects.
uhm. No. A simple bus/train/tram stop simply stays relatively simple and 
relation-less:


public_transport=stop_position
bus/tram/rail/subway=yes
name=West Station

+

public_transport=platform
name=West Station

You don't need any stop_area or whatever relation to combine those two 
nodes/ways. You can do, but most PT websites will be able to link those 
two without.


Claudius

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Public transport proposal

[Claudius Henrichs]

Am 13.01.2011 21:33, Michał Borsuk:



On 13 January 2011 13:59, André Joost > wrote:


Am 13.01.11 13:27, schrieb Richard Fairhurst:

Could I have your assurance that the proponents of this
proposal will
also be providing good-quality patches for the three principal
editors
(Potlatch, JOSM, Merkaartor), with an easy-to-use interface
consistent
with the rest of the editor?


A preset for josm is already in progress.


With what's in the proposal? That's pretty arogant, don't you find?  
We haven't decided on the final shape yet.
I don't see any arrogance here. Have you used JOSM before? I guess you 
did so you know that presets must be actively downloaded and enabled by 
the users hidden in the preferences. Somewhere besides the "Doctors in 
Greece", the "OpenPisteMap" and the "Japanese 50 sounds order" presets.
A preset could help testing the proposal during daily work and in the 
daily environment to see if it works like it as envisioned. Still I 
can't see no arrogance anywhere. And btw I like this do-ocratic part of  
JOSM just like some well intentioned exchange of ideas.

Claudius
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport

[Claudius Henrichs]

Am 14.01.2011 02:16, Tobias Knerr:

Dominik Mahrer wrote:

One month ago I already posted an RFC on this proposal. In the meantime
I got plenty of comments and I have extended/corrected/rewritten nearly
the whole proposal.

I'm not very happy with the extensive use of relations. Especially
nested relations strongly suggest that the level of complexity is beyond
what's appropriate for a crowd-sourced project like OSM.

The most prominent issue are stop area groups. The necessity of these
has already been questioned. I, too, tend to think that determining them
algorithmically would ultimately be a better choice. Removing the nested
relations for stop area groups would eliminate one of the most complex
concepts from the proposal, making it more accessible to mappers.

Additionally, I suggest to reconsider the requirement to use stop area
relations even in simple cases Many bus stops are very straightforward:
They consist of usually two platforms with a common name. This name is
usually unique within a range of several kilometres and, if tagged to
the platform elements, could therefore be used instead of a relation to
identify the components of the stop area.

+1
I don't think the stop_area-relation for the vast majority of simple 
bus, tram or train stops is necessary. öpnvkarte.de and other sites 
working with the data prove that you can reliably determine nodes 
belonging to one stop via easy algorithms/preprocessing.


Claudius

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

[Talk-transit] JOSM latest takes forward/backward roles for route relations into account

[Claudius Henrichs]

Just a small hint on anyone working with relations using 
"forward/backward" roles and willing to do some experimenting: The 
latest JOSM (starting from revision 3788) includes a nice relation 
analysis and visualisation for these relations. See this ticket (scroll 
down for some interesting screenshots): 
http://josm.openstreetmap.de/ticket/5109


Would be great if you could test this build with your relations and 
report possible issues. Be aware though that this isn't a tested release 
so you might encounter weird behaviour, data corruption and all other 
joys of beta testing.

Download the latest JOSm from http://josm.openstreetmap.de

Claudius


___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Summary of Public Transport Proposal Criticism

[Claudius Henrichs]

Am 22.01.2011 09:32, Dominik Mahrer (Teddy):

I try to seperate the criticism from the spam around my proposal:

- stop_area is not needed/too complicated:
According to taginfo there are already 64'500 stop area relations in 
the OSM database (10'500 public transport/oxomoa, 1'500 stop place, 
51'500 unified stoparea).
For me this is a reasonable number and we can't say it is only a 
minority of eccentric mappers. It is a widely used tagging schema, 
badly with several flavors. And it does not seam to be too 
complicated, otherwise it would not be that much.
Just one comment to this point: What you can't justify by statistics is 
the ten thousand of cases were users deliberately decided *not* to use a 
stop_area relation but simply created public_transport=stop_position and 
public_transport=platform nodes with the same name next to each other. 
So just like your comment for the route_master...



- route_master is not needed:
If all the information is tagged at the variants/directions it is not 
really needed, this is correct. I thought it is clearly described in 
the proposal that you can skip the route_master if you think it is not 
needed.
...you should add to your proposal that you can leave away the stop_area 
relation for simply stop positions.


Otherwise I'm okay with your summary and the proposal.

Claudius

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Public Transport Line Diagram

[Claudius Henrichs]

Am 25.01.2011 18:30, Wojciech Kulesza:
Was wondering if the planned changes to approach in mapping public 
transport would have an impact on this service:

http://78.46.81.38/public_transport.html

While it behaves quite nicely for the examples provided there, it 
works very bad for PT in Poland.


Compare this result: 
http://78.46.81.38/api/sketch-line?network=ZTM+Pozna%C5%84&ref=1 



with the appropariate relation in osm:
http://www.openstreetmap.org/browse/relation/79152
Just compare your relation with the working one :) 
http://www.openstreetmap.org/browse/relation/361959
On first sight i'm wondering why you are mixing "railway=halt" and 
"railway=tram_stop"? Isn't all of it a tram line? Additionally you are 
missing "from=" and "to=" in your relation.


Claudius

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit