Re: [OSM-talk] TAG-Suggestion: highway:trailer_shipment (Carsten Moeller)
Richard Bullock wrote: >> A highway=steps would imply you can use your car here. >> > > > http://wiki.openstreetmap.org/wiki/Image:Steps.jpg > You wouldn't *seriously* consider driving up or down a flight of > steps...surely?? The Italian Job? ;-) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] TAG-Suggestion: highway:trailer_shipment (Carsten Moeller)
Richard Bullock schrieb: >> A highway=steps would imply you can use your car here. > > > http://wiki.openstreetmap.org/wiki/Image:Steps.jpg > You wouldn't *seriously* consider driving up or down a flight of > steps...surely?? > >> If I understood the intention correctly then highway is something you can >> drive on. > > No. The highway key is a group of tags, some of which would imply you can > drive on, some you cannot. In England, a public highway could include a > narrow footpath through a field, where cars are forbidden and it could be > completely unsuitable for vehicles - up to an 8-lane motorway, where > pedestrians are forbidden. > > The only ones I'd consider that a car could route over would be > highway= motorway > trunk > primary > secondary > tertiary > unclassified > service > With the possible addition of > track or byway as a last resort Answer is posted in the thread. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] TAG-Suggestion: highway:trailer_shipment
Richard Bullock schrieb: >> A highway=steps would imply you can use your car here. > > > http://wiki.openstreetmap.org/wiki/Image:Steps.jpg > You wouldn't *seriously* consider driving up or down a flight of > steps...surely?? > >> If I understood the intention correctly then highway is something you can >> drive on. > > No. The highway key is a group of tags, some of which would imply you can > drive on, some you cannot. In England, a public highway could include a > narrow footpath through a field, where cars are forbidden and it could be > completely unsuitable for vehicles - up to an 8-lane motorway, where > pedestrians are forbidden. > > The only ones I'd consider that a car could route over would be > highway= motorway > trunk > primary > secondary > tertiary > unclassified > service + corresponding _link(s) > With the possible addition of > track or byway as a last resort Maybe there is sth. wrong in my dictionary. Sorry if so. The word highway itself seems the problem. But it's not my intention to change things here. We already have highway=pedestrian. That's satisfactory. As I said before. I'm trying to combine pgrouting and OSM in a private project. I mentioned the need to keep things simple. The handling of some tags overloads the data and the complexity for parsing a suitable routing table. For my taste even the turning restrictions could be handled simpler. But that doesn't matter. Parsing this out is simple. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] TAG-Suggestion: highway:trailer_shipment (Carsten Moeller)
> A highway=steps would imply you can use your car here. http://wiki.openstreetmap.org/wiki/Image:Steps.jpg You wouldn't *seriously* consider driving up or down a flight of steps...surely?? > If I understood the intention correctly then highway is something you can > drive on. No. The highway key is a group of tags, some of which would imply you can drive on, some you cannot. In England, a public highway could include a narrow footpath through a field, where cars are forbidden and it could be completely unsuitable for vehicles - up to an 8-lane motorway, where pedestrians are forbidden. The only ones I'd consider that a car could route over would be highway= motorway trunk primary secondary tertiary unclassified service With the possible addition of track or byway as a last resort ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] TAG-Suggestion: highway:trailer_shipment
On Sun, Jan 17, 2010 at 10:14 PM, Carsten Moeller wrote: > I do agree. Railways, aerialway etc. should be connected to highways. > But this should not be expressed by connecting same nodes. Here ramps or > links come into play. If you have a closer look at todays OSM-Data I think there is a general need here to express "connections" separately from the ways themselves. In the case of bike paths (sorry to be a one tune band), They frequently seem to pass very near a road without there actually being an explicit piece of pavement connecting them. You want to map this "connection", but if you draw a "highway=cycleway", you're mapping something that is not technically there. Something as simple as "path=none" might suffice in a lot of instances, to indicate that a connection has all the other qualities of that way, but there is nothing to see physically. Whether or not such a thing should be rendered on a map is another, interesting question. Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] TAG-Suggestion: highway:trailer_shipment
Felix Hartmann schrieb: > I think the main part that has to be done here is that ferries, or > motorails however as well aerialways get connected to the main road > network using lines (routing over polygons is so complicated that no > router will soon master it in a useful way). > > How they are connected should be dependant on the transport mode to use. > Image huge ferries with different, but consistent places to enter. > > We could have > highway=footway & pier=yes (or similar)for pedestrians entering the > ferry (this is actually one of the rare cases I like to see footway and > not path), > highway=service & motorcycle=yes & foot=no & bicycle=yes > highway=service & access=no & motorcar=yes & hgv=yes > > And the ferry route should connect all three. > > Another example would be a cable_car. > We should have highway=footway (or another key) to connect the street > network to the cable_car. If there are steps inside the building, well > then lets add a section highway=steps.. > > > The principle should be no matter what kind of line there is that can be > used somehow, it should be interconnected with all other transport > usable lines. This means that we should also connect railways to roads, > because otherwise no autorouter can calculate routes using busses and > trains (with walking from one to another) for example. Only airports I > would rather just connect by having a relation list to which other > airports you can get from airport XY. I get to the conclusion that we exactly have two perspectives. First there is the question of how to get from A to B including public means of transport. The other one guides me to the closest parking lot. A cable car for instance has the same quality as an aerialway. But not as highway=footway. The latter is rather like a highway=service. You can use a car. Ok. it might be forbidden but you can. Offering mountain tops and similar things as addresses on your routing topology will blow up the data dramatically. The key to a fast routing is the reduction of data. "Make things as simple as possible, but not simpler" (Einstein). There are some grey zones. I am living in a "highway=pedestrian" connected to a "highway=service", so I decided to take these tags into account but gave them a low priority so the router selects them only if there is no other way. I do agree. Railways, aerialway etc. should be connected to highways. But this should not be expressed by connecting same nodes. Here ramps or links come into play. If you have a closer look at todays OSM-Data railways are in fact connected to streets. But I wonder if you'd like to stop a train by parking your car on a railroad crossing ;-) What about aerialways? Are they connected, too? In the air? A highway=steps would imply you can use your car here. I think we should strictly distinguish between highway and other tags. If I understood the intention correctly then highway is something you can drive on. Even on highway=pedestrian but not on steps. I hope OSM will take these two perspectives into accoung one day. So we can have routable highway tags like highway=railway, highway=ferry, etc. These are much easier to handle (and to tag) than railway=rail + motorcar=yes + amenity= ... and so on. On the other hand we should consider the real world. This of course means we'll need to build topologies on relations or tags like motorcar=yes, railway=rail. Regards Carsten (alias PiMapper) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] TAG-Suggestion: highway:trailer_shipment
I think the main part that has to be done here is that ferries, or motorails however as well aerialways get connected to the main road network using lines (routing over polygons is so complicated that no router will soon master it in a useful way). How they are connected should be dependant on the transport mode to use. Image huge ferries with different, but consistent places to enter. We could have highway=footway & pier=yes (or similar)for pedestrians entering the ferry (this is actually one of the rare cases I like to see footway and not path), highway=service & motorcycle=yes & foot=no & bicycle=yes highway=service & access=no & motorcar=yes & hgv=yes And the ferry route should connect all three. Another example would be a cable_car. We should have highway=footway (or another key) to connect the street network to the cable_car. If there are steps inside the building, well then lets add a section highway=steps.. The principle should be no matter what kind of line there is that can be used somehow, it should be interconnected with all other transport usable lines. This means that we should also connect railways to roads, because otherwise no autorouter can calculate routes using busses and trains (with walking from one to another) for example. Only airports I would rather just connect by having a relation list to which other airports you can get from airport XY. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] TAG-Suggestion: highway:trailer_shipment
Ulf Lamping schrieb: > Am 16.01.2010 10:16, schrieb Carsten Moeller: >> 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. > > Sorry to say, if you don't take highway=service ways into account, your > whole routing program gets very certainly a lot less useful to a lot of > end users anyway. > >> 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. > > That's true. But it should be as simple as possible for the mappers (as > long as it's somehow usable for routers) :-) > > If you say "the mappers have to improve tagging, otherwise I won't be > able to write a router" I'd say "write a better router". It's not > because I don't like you, it's because I know that half of the mappers > won't do it anyway and you'll just end up with a router not working in a > lot of situations. > >> I'm afraid, only few >> people will follow this tagging pattern and we'll end up in a forest. > > That's no news, regardless of what we'll discuss here ;-) > >> 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. > > If you don't want to analyze relations, you will also miss other > required stuff (e.g. turn restrictions). A router not analyzing > relations has no future IMHO. > >> 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. > > No, it doesn't ;-) > > Regards, ULFL Oh dear, don't remind me of the turning restrictions ~~~ This is another non fitting pair of shoes ;-) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] TAG-Suggestion: highway:trailer_shipment
Am 16.01.2010 10:16, schrieb Carsten Moeller: > 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. Sorry to say, if you don't take highway=service ways into account, your whole routing program gets very certainly a lot less useful to a lot of end users anyway. > 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. That's true. But it should be as simple as possible for the mappers (as long as it's somehow usable for routers) :-) If you say "the mappers have to improve tagging, otherwise I won't be able to write a router" I'd say "write a better router". It's not because I don't like you, it's because I know that half of the mappers won't do it anyway and you'll just end up with a router not working in a lot of situations. > I'm afraid, only few > people will follow this tagging pattern and we'll end up in a forest. That's no news, regardless of what we'll discuss here ;-) > 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. If you don't want to analyze relations, you will also miss other required stuff (e.g. turn restrictions). A router not analyzing relations has no future IMHO. > 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. No, it doesn't ;-) Regards, ULFL ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] TAG-Suggestion: highway:trailer_shipment
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. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] TAG-Suggestion: highway:trailer_shipment
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 ;-) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] TAG-Suggestion: highway:trailer_shipment
Ulf Lamping schrieb: > Am 15.01.2010 15:43, schrieb Carsten Moeller: >> Hey folks, >> >> first of all I'll have to apologize my bad english. >> I also hope that this is the right place for my question. >> >> I'm playing around with pgRouting and OSM - mainly in the north of >> Germany. (Schleswig-Holstein / Hamburg) >> I came across some annoying issues. >> There are several islands that can only be reached by ferry or train. >> So I filtered tags like railway=rail, route=ferry in combination with >> motorway=yes (For the germans: you all should know the Hindenburdamm to >> the island Sylt). >> The first thing that is quite wrong is that streets are connected to >> railroads the whole way long. In case of Sylt you exactly have one ramp >> in Niebuell and another in Westerland (Sylt). In between you have to go >> pickapack. By the way, it's the same problem with the ferries. >> >> So, as these kinds of transports' main purpose is "replacing" highways, >> they should be regardes AS highways. >> >> So what about tags like >> >> highway = trailer_railway >> highway = trailer_ferry >> >> we then could connect them to streets as if they were highways. > > Just yesterday I've collected infos about a more general approach to > this. However, I've focussed on the terminals and not on the way between > them. > > The problem: This stuff is also available for "long distance" (e.g. > overnight) travel from north to south europe with varying routes, so > simply using highway=trailer_railway probably won't work well here. > Maybe better using a relation for this? > > I've appended my first ideas for a proposal page. > > Regards, ULFL > > > motorail > > Regular transportation of car/motorcycle "packed" on a train and travels > to the destination. > The driver travels together with it's vehicle and may need to stay > inside the vehicle or travels in a normal (or sleeping) train waggon. > > Both short term (e.g. through the channel tunnel) and long term (e.g. > overnight from Hamburg to Vienna) travels are common. > > This is *not* for plain car transportation, e.g. delivering a newly > build car from the manufacturer to it's a customer. > > > What to tag: > The specific place to "board the train". > > Suggested tag: > amenity=motorail_terminal (on node or area) > name=* (e.g. Autozug Terminal München-Ost) > operator=* (e.g. Deutsch Bahn AG) > > Clarify: > Also tag route/destinations? Maybe using relations? > > See Also > amenity=ferry_terminal > > Weblinks > http://en.wikipedia.org/wiki/Motorail > http://de.wikipedia.org/wiki/Autoverladung (german) Hello Ulf ... 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". From the perspective of a "street map" a pickapack railway or ferry has the same quality as e.g. highway=pedestrian. 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. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] TAG-Suggestion: highway:trailer_shipment
Am 15.01.2010 15:43, schrieb Carsten Moeller: > Hey folks, > > first of all I'll have to apologize my bad english. > I also hope that this is the right place for my question. > > I'm playing around with pgRouting and OSM - mainly in the north of > Germany. (Schleswig-Holstein / Hamburg) > I came across some annoying issues. > There are several islands that can only be reached by ferry or train. > So I filtered tags like railway=rail, route=ferry in combination with > motorway=yes (For the germans: you all should know the Hindenburdamm to > the island Sylt). > The first thing that is quite wrong is that streets are connected to > railroads the whole way long. In case of Sylt you exactly have one ramp > in Niebuell and another in Westerland (Sylt). In between you have to go > pickapack. By the way, it's the same problem with the ferries. > > So, as these kinds of transports' main purpose is "replacing" highways, > they should be regardes AS highways. > > So what about tags like > > highway = trailer_railway > highway = trailer_ferry > > we then could connect them to streets as if they were highways. Just yesterday I've collected infos about a more general approach to this. However, I've focussed on the terminals and not on the way between them. The problem: This stuff is also available for "long distance" (e.g. overnight) travel from north to south europe with varying routes, so simply using highway=trailer_railway probably won't work well here. Maybe better using a relation for this? I've appended my first ideas for a proposal page. Regards, ULFL motorail Regular transportation of car/motorcycle "packed" on a train and travels to the destination. The driver travels together with it's vehicle and may need to stay inside the vehicle or travels in a normal (or sleeping) train waggon. Both short term (e.g. through the channel tunnel) and long term (e.g. overnight from Hamburg to Vienna) travels are common. This is *not* for plain car transportation, e.g. delivering a newly build car from the manufacturer to it's a customer. What to tag: The specific place to "board the train". Suggested tag: amenity=motorail_terminal (on node or area) name=* (e.g. Autozug Terminal München-Ost) operator=* (e.g. Deutsch Bahn AG) Clarify: Also tag route/destinations? Maybe using relations? See Also amenity=ferry_terminal Weblinks http://en.wikipedia.org/wiki/Motorail http://de.wikipedia.org/wiki/Autoverladung (german) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
