[OSM-talk] TAG-Suggestion: highway:trailer_shipment

[Carsten Moeller]

Ulf Lamping schrieb:
> Am 15.01.2010 23:02, schrieb Carsten Moeller:
>> yes, osm relations are one possible solution. But from the view of a
>> pgRouter it is a very stony way to collect that data back into a routing
>> table. You are right, that there should be a tag like "terminal" or
>> "ramp" or even simpler "link".
> 
> Seems there's at least no "difference in principle" that this would be 
> useful :-)
> 
> We already have the established amenity=ferry_terminal and an 
> amenity=motorail_terminal wouldn't be very different in functionality - 
> no need to develop a complete new name IMHO.
> 
> As you certainly want to have a different rendering for these two, it 
> might not be a good idea to have just a single tag like amenity=terminal 
> for this.
> 
>>   From the perspective of a "street map" a pickapack railway or ferry has
>> the same quality as e.g. highway=pedestrian.
> 
> Sorry, i don't get your point here. On highway=pedestrian I'm not 
> allowed to drive (except maybe for un-/loading at specific times) - 
> which is completely different IMHO.
> 
>> So I'd prefer sth. like highway=railway, highway=ferry,
>> highway=railway_link and highway=ferry_link.
>> This info is enough for pgRouting to create a topology.
>> Additional properties can be assigned to "amenity" or "railway" of course.
> 
> For a ferry (if all is tagged well), this can already be achieved. 
> You'll travel:
> 
> highway=service
> amenity=ferry_terminal (if it allows cargo=vehicle)
> ferry route (as tagged and displayed already on the maps)
> amenity=ferry_terminal (again with cargo=vehicle)
> highway=service
> 
> The same principle applies for a railway as well:
> 
> highway=service
> amenity=motorail_terminal
> motorail route (see below)
> amenity=motorail_terminal
> highway=service
> 
> The exception for the railway - compared with ferries - is, that the 
> "railway grid" will physically connect a lot of places. There's 
> certainly a physical railway connection from the sylt shuttle mainland 
> station to italy. But the railway company just won't offer you that 
> service :-)
> 
> Now you can invent a special tag (as you intended) for the short 
> distance or "point to point" connections, like sylt shuttle, channel 
> tunnel and alike applies for several short distance tunnel services in 
> the alps.
> 
> Then you'll need *another* mechanism for the long distance travel from 
> hamburg to vienna (Deutsche Bahn is offering about roughly 20 such 
> dedicated routes - not more) with just exactly the same problem: Travel 
> with your car pickapack on a train from A to B. That's why I was 
> thinking about relations.
> 
> 
> However, as you may want to display on a map only short distance but not 
> long distance pickapack, it even makes sense IMO to have two different 
> ways to tag this. One to tag "point to point" connections as you'd 
> suggested and one for "long distance connection grid" connections using 
> relations.
> 
> 
> May I suggest to just keep existing stuff for ferries and use 
> amenity=motorail_terminal and highway=motorail (which seems to be the 
> right translation for german Autoverladung/Autoreisezug) for the short 
> distance ways?
> 
> Regards, ULFL
> 
> P.S: Next time, using the tagging mailing list seems more natural for 
> these or similar discussions ;-)

Yes, I do agree. We should have tags describing short and long 
distances. The latter is possibly best expressed by using relations.
Yes, there are already tags for our problem:

highway=service
amenity=ferry_terminal (if it allows cargo=vehicle)
ferry route (as tagged and displayed already on the maps)
amenity=ferry_terminal (again with cargo=vehicle)
highway=service

But this kind of tagging is hardly parsable. In case of routing, I don't 
want to collect all highway=service in the topo. For route=ferry or 
rail=railway I can distinguish if they are subtagged by motorcar=true or 
not. As a consequence the highway=service then should be subtagged with 
sth. like "ferry-link". But this guides me to my first approach again. 
In my opinion, it should be as simple as possible. I'm afraid, only few 
people will follow this tagging pattern and we'll end up in a forest.
Once again, the main problem is the parsing itself. In case of the upper 
example you will have to analyze relations in a second step. If you 
tagged them directly It's just a one shot parsing.
Another problem, as I've already mentioned before, are the connections 
(even same nodes) between railroads and streets. This is a annoying and 
kills the ability for OSM to route satisfyingly.