[OSM-talk] OpenStreetMap routing service
Another excellent routing service! A question: Is there an API? Is it possible to query the routing engine programmatically? (I would like to be able to send a query from my mom application running in Java ME on a mobile phone.) elvin From: Lambertus [EMAIL PROTECTED] Date: 6 September 2008 16:06:28 BDT To: [EMAIL PROTECTED], talk@openstreetmap.org Subject: [OSM-talk] OpenStreetMap routing service Reply-To: Lambertus [EMAIL PROTECTED] A few hours ago a new version of the OpenStreetMap Routing Service has come online. I think is has evolved enough to go public 'officially'... The (yet another, I know) OpenStreetMap Routing Service is linking together off-the-shelf software such as Gosmore routing engine, Gazetteer namefinder service, Route altitude profiler, Potlatch online editor and OpenLayers framework. This version includes some UI bugfixes for leftover markers and marker placement 'lag'. There's also better support for Internet Explorer, usage of the available display area and help text (still rudimentary). New in this version is the 'Edit map' button which is particulary useful when testing and debugging the OSM way- and routedata (e.g. restrictions, oneway streets and disconnected intersections). Once you've spotted an error you can click this button and the online 'Potlatch' map editor will be opened in a new window containing the current map view. Although this service supports routing throughout Europe, Asia, Africa and Oceania, routing in the America's (North and South) is currently not possible. The North American data is so massive that it needs a 64bit server for the routing engine (Gosmore), currently the sponsored server runs a 32bit OS. I hope to work around this problem by splitting America into three areas (Northeast, Northwest and South) but - unfortunately - this will prohibit routing from one area to another. I hope this effort in collecting readily available software will be useful in validating/improving the data, inspire further software developement and attract new contributors. Please give it a try and tell me what you think: http://tile.openstreetmap.nl/~lambertus/routing-world ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] amenity=vending_machine AND amenity=post_box: what about?
On Sun, Sep 7, 2008 at 10:53 PM, Norbert Wenzel [EMAIL PROTECTED] wrote: Shaun McDonald wrote: The problem with this is that none of the editors support having duplicate key values, even so the 0.5 API supports it. The 0.6 API will not support duplicate key values. I think the support of duplicate keys is a very much needed feature and I personally would drop it only, if there are really good reasons (e.g. breaking fast queries, etc.) to drop it. It would be possible to tag something like amenity=supermarket; post_office; but as stated in another discussion yesterday that would make searching for entries much more complicated. Just to name a few very common cases where duplicate keys would be necessary I'd like to point out the very common case of hotels also having a publicly available restaurant. Of course one could draw a building and drop all needed amenities inside, but I think that wouldn't be routable unless you add the addr: properties to every node inside that building. So personally I think duplicate keys would be the easiest and best way to tag such double-uses. Norbert Just make two different nodes, each located closest to the amenity concerned. There's nothing that makes it non-routable. It's just a point--the routers will get you as close to the point on the road as possible. The addr: property definitely isn't going to help in making it routable. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap routing service
Lars Aronsson wrote: Lambertus wrote: Perhaps an inventory of the countries that allow cyclists on trunks and motorways has to be created. Here you assume that trunk is a well defined concept. But it isn't. Maybe I should have written 'allow or deny access...', that's what I meant: a list of default features for each country for each road type found in the map_features even if it's not used. There are no roads in Scandinavia that are called trunk roads. So we have to invent our own understanding of when to use this label. Unfortunately, the Finns and Norwegians made a different interpretation than the Swedes. So at some zoom levels, it looks as if Norway and Finland are full of green trunk roads, while Sweden is a country with very few roads. Because we labeled those roads as primary, which are not rendered at that zoom level. I think we should change all Swedish riksväg roads from primary to trunk, to match the definition used for Norway and Finland, and to make the map of Sweden look less empty at some zoom levels. Here the dogma 'Don't change the tagging just to get it rendered' applies :-) I think it would be better to judge the roads on what their function is and try to correlate those roads to the map features page by their description. But this may well be that perhaps some ways in Sweden have to be reclassified to trunk or that some ways in Norway /Finland should be classified primary, I don't know that. However, even though the speed limit on a Swedish riksväg (similar to a German Bundesstrasse) is mostly 90 km/h (sometimes 70 km/h), you are allowed to drive tractors and bicycles there. There is ofcourse also the chance that Sweden just does not have a road type that fits the trunk type between motorway and primary, however from what I read in other mails it appears that cyclists are allowed on most trunk roads in GB. Sometimes tagging isn't just doesn't seem rational but requires compromises... ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Access restrictions: hazardous material other details
Sebastian Hohmann wrote: Norbert Wenzel schrieb: Hi, I just mapped a street and did not find a proper access tag. The sign can be found in Wikimedia Commons [0]. It says it is forbidden to drive with hazardous material. I don't think I'm the first one to map such streets, since those signs are relatively common, so Is there any solution how to tag such restrictions? There is a page that lists all road signs for Germany. They look a bit different than yours, but at least those two mean the same. http://wiki.openstreetmap.org/index.php/De:Road_Signs Unfortunately there doesn't seem to be a tag for hazardous materials yet. A possibility would be: hazardous=no/yes/.. ? Thanks for the link to the list. It's a great reference, especially since the road signs only differ in the style they are drawn between Austria and Germany. I used hazmat=no or something like that. I think it's worth an amendment to the access property, since it's relatively common in Austria and Bavaria due to the great number of springs, rivers or tunnels. The list also helped solving my second problem, the motorvehicle=no tag. It seems that goods are forbidden when motorcars are unless stated otherwise. thanks, Norbert smime.p7s Description: S/MIME Cryptographic Signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] amenity=vending_machine AND amenity=post_box: what about?
Karl Newman wrote: Just make two different nodes, each located closest to the amenity concerned. There's nothing that makes it non-routable. It's just a point--the routers will get you as close to the point on the road as possible. The addr: property definitely isn't going to help in making it routable. You're right with the addr: property, that was not well thought from my side. But I'd nevertheless prefer the double amenities, just because the that's what those nodes are. One building or machine with multiple uses at the very same place. Norbert smime.p7s Description: S/MIME Cryptographic Signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] amenity=vending_machine AND amenity=post_box: what about?
On Mon, Sep 8, 2008 at 10:33 AM, Norbert Wenzel [EMAIL PROTECTED] wrote: Karl Newman wrote: Just make two different nodes, each located closest to the amenity concerned. There's nothing that makes it non-routable. It's just a point--the routers will get you as close to the point on the road as possible. The addr: property definitely isn't going to help in making it routable. You're right with the addr: property, that was not well thought from my side. But I'd nevertheless prefer the double amenities, just because the that's what those nodes are. One building or machine with multiple uses at the very same place. Norbert I understand your concern about overlapping icons, but in a device such as a GPS, it will be considered as two separate points of interest (POI), because it really is two different services (or amenities or whatever); they just happen to be at the same location. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap routing service
2008/9/8 Nic Roets [EMAIL PROTECTED]: Next mappers will omit units of measurement because they feel it it's implied for their country. I omit units because I feel they are implied for the _world_. Map features, unless it has been changed since, takes the view that, for instance, width and maxspeed are understood to be in m and km/h. Subsequent discussion has decided that units should be permitted, and there are many opinions for or against this, but let's be careful in our definitions of normality... Dermot -- -- Iren sind menschlich ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] fietsen door de Ijtunnel
Ijtunnel is ook getagd als highway=motorway, kortom snelweg dus. En daar mag je in Nederland ook niet fietsen. Dus het effect is hetzelfde. We zouden gewoon een lijstje (op de wiki en netjes in xml) moeten hebben (per land) over waar je wel mag fietsen/lopen etc. Volgens mij is er op de wiki al zo'n lijstje kon hem alleen even niet zo snel vinden. Maar dan zouden dit soort dingen sowieso niet mogen. Net als dat je in Nederland niet over een autoweg mag fietsen en in de bebouwde kom eigenlijk overal mag fietsen tenzij anders aangegeven/fietspad beschikbaar is. --Roeland On Monday 08 September 2008 10:09:56 Martijn van Exel wrote: Bij een weg van de categorie 'autoweg' zou dat impliciet moeten zijn volgens mij. Ik weet niet zeker of de IJtunnelweg daaronder valt, de Nieuwe Leeuwarderweg (aan de noordzijde) in het verleden in elk geval wel. http://nl.wikipedia.org/wiki/Autoweg Martijn 2008/9/8 Lambert Carsten [EMAIL PROTECTED]: Hoi, Naar aanleiding van een bericht op de engelse talk lijst van Lambertus over een nieuwe versie van de route planner (dat er zoietsl bestond buiten Duitsland was mij zelfs ontgaan!): http://tile.openstreetmap.nl/~lambertus/routing-world testte ik het even uit en ontdekte dat ik door de ijtunnel in Amsterdam kon fietsen! Niets ten nadele van de route planner. Wat ontzettend gaaf dat dit er eindelijk is. Ik heb snel even bicycle=no en foot=no tags toegevoegd aan de ijtunnel, maar eigenlijk moet er ook zaken als horse=no en agricultural=no bij en wat er verder aan tags verzonnen worden. Weet iemand hier een beter oplossing voor? Lambert ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] fietsen door de Ijtunnel
Woeps sorry mijn fout. Is wel een autoweg. Het is nog vroeg he... On Monday 08 September 2008 10:18:44 Roeland Douma wrote: Ijtunnel is ook getagd als highway=motorway, kortom snelweg dus. En daar mag je in Nederland ook niet fietsen. Dus het effect is hetzelfde. We zouden gewoon een lijstje (op de wiki en netjes in xml) moeten hebben (per land) over waar je wel mag fietsen/lopen etc. Volgens mij is er op de wiki al zo'n lijstje kon hem alleen even niet zo snel vinden. Maar dan zouden dit soort dingen sowieso niet mogen. Net als dat je in Nederland niet over een autoweg mag fietsen en in de bebouwde kom eigenlijk overal mag fietsen tenzij anders aangegeven/fietspad beschikbaar is. --Roeland On Monday 08 September 2008 10:09:56 Martijn van Exel wrote: Bij een weg van de categorie 'autoweg' zou dat impliciet moeten zijn volgens mij. Ik weet niet zeker of de IJtunnelweg daaronder valt, de Nieuwe Leeuwarderweg (aan de noordzijde) in het verleden in elk geval wel. http://nl.wikipedia.org/wiki/Autoweg Martijn 2008/9/8 Lambert Carsten [EMAIL PROTECTED]: Hoi, Naar aanleiding van een bericht op de engelse talk lijst van Lambertus over een nieuwe versie van de route planner (dat er zoietsl bestond buiten Duitsland was mij zelfs ontgaan!): http://tile.openstreetmap.nl/~lambertus/routing-world testte ik het even uit en ontdekte dat ik door de ijtunnel in Amsterdam kon fietsen! Niets ten nadele van de route planner. Wat ontzettend gaaf dat dit er eindelijk is. Ik heb snel even bicycle=no en foot=no tags toegevoegd aan de ijtunnel, maar eigenlijk moet er ook zaken als horse=no en agricultural=no bij en wat er verder aan tags verzonnen worden. Weet iemand hier een beter oplossing voor? Lambert ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] fietsen door de Ijtunnel
Het was volgens mij tot voor kort een trunk road. Ik heb dat veranderd in Primary omdat het begrip 'trunk road' voor de Nederlandse wegenindeling volgens mij geen betekenis heeft. Maar voor autowegen zou dat inderdaad impliciet mogen zijn: geen langzaam verkeer. 2008/9/8 Roeland Douma [EMAIL PROTECTED]: Woeps sorry mijn fout. Is wel een autoweg. Het is nog vroeg he... On Monday 08 September 2008 10:18:44 Roeland Douma wrote: Ijtunnel is ook getagd als highway=motorway, kortom snelweg dus. En daar mag je in Nederland ook niet fietsen. Dus het effect is hetzelfde. We zouden gewoon een lijstje (op de wiki en netjes in xml) moeten hebben (per land) over waar je wel mag fietsen/lopen etc. Volgens mij is er op de wiki al zo'n lijstje kon hem alleen even niet zo snel vinden. Maar dan zouden dit soort dingen sowieso niet mogen. Net als dat je in Nederland niet over een autoweg mag fietsen en in de bebouwde kom eigenlijk overal mag fietsen tenzij anders aangegeven/fietspad beschikbaar is. --Roeland On Monday 08 September 2008 10:09:56 Martijn van Exel wrote: Bij een weg van de categorie 'autoweg' zou dat impliciet moeten zijn volgens mij. Ik weet niet zeker of de IJtunnelweg daaronder valt, de Nieuwe Leeuwarderweg (aan de noordzijde) in het verleden in elk geval wel. http://nl.wikipedia.org/wiki/Autoweg Martijn 2008/9/8 Lambert Carsten [EMAIL PROTECTED]: Hoi, Naar aanleiding van een bericht op de engelse talk lijst van Lambertus over een nieuwe versie van de route planner (dat er zoietsl bestond buiten Duitsland was mij zelfs ontgaan!): http://tile.openstreetmap.nl/~lambertus/routing-world testte ik het even uit en ontdekte dat ik door de ijtunnel in Amsterdam kon fietsen! Niets ten nadele van de route planner. Wat ontzettend gaaf dat dit er eindelijk is. Ik heb snel even bicycle=no en foot=no tags toegevoegd aan de ijtunnel, maar eigenlijk moet er ook zaken als horse=no en agricultural=no bij en wat er verder aan tags verzonnen worden. Weet iemand hier een beter oplossing voor? Lambert ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl -- martijn van exel -+- [EMAIL PROTECTED] -+- http://www.schaaltreinen.nl/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] fietsen door de Ijtunnel
Trunk road is toch hier in nederland gewoon autoweg? http://wiki.openstreetmap.org/index.php/Nl:The_Netherlands_roads_tagging Want primary zijn de wegen door de een stad (Sxxx) ook en daar mag je dan vaak wel weer fietsen. --Roeland On Monday 08 September 2008 10:32:33 Martijn van Exel wrote: Het was volgens mij tot voor kort een trunk road. Ik heb dat veranderd in Primary omdat het begrip 'trunk road' voor de Nederlandse wegenindeling volgens mij geen betekenis heeft. Maar voor autowegen zou dat inderdaad impliciet mogen zijn: geen langzaam verkeer. 2008/9/8 Roeland Douma [EMAIL PROTECTED]: Woeps sorry mijn fout. Is wel een autoweg. Het is nog vroeg he... On Monday 08 September 2008 10:18:44 Roeland Douma wrote: Ijtunnel is ook getagd als highway=motorway, kortom snelweg dus. En daar mag je in Nederland ook niet fietsen. Dus het effect is hetzelfde. We zouden gewoon een lijstje (op de wiki en netjes in xml) moeten hebben (per land) over waar je wel mag fietsen/lopen etc. Volgens mij is er op de wiki al zo'n lijstje kon hem alleen even niet zo snel vinden. Maar dan zouden dit soort dingen sowieso niet mogen. Net als dat je in Nederland niet over een autoweg mag fietsen en in de bebouwde kom eigenlijk overal mag fietsen tenzij anders aangegeven/fietspad beschikbaar is. --Roeland On Monday 08 September 2008 10:09:56 Martijn van Exel wrote: Bij een weg van de categorie 'autoweg' zou dat impliciet moeten zijn volgens mij. Ik weet niet zeker of de IJtunnelweg daaronder valt, de Nieuwe Leeuwarderweg (aan de noordzijde) in het verleden in elk geval wel. http://nl.wikipedia.org/wiki/Autoweg Martijn 2008/9/8 Lambert Carsten [EMAIL PROTECTED]: Hoi, Naar aanleiding van een bericht op de engelse talk lijst van Lambertus over een nieuwe versie van de route planner (dat er zoietsl bestond buiten Duitsland was mij zelfs ontgaan!): http://tile.openstreetmap.nl/~lambertus/routing-world testte ik het even uit en ontdekte dat ik door de ijtunnel in Amsterdam kon fietsen! Niets ten nadele van de route planner. Wat ontzettend gaaf dat dit er eindelijk is. Ik heb snel even bicycle=no en foot=no tags toegevoegd aan de ijtunnel, maar eigenlijk moet er ook zaken als horse=no en agricultural=no bij en wat er verder aan tags verzonnen worden. Weet iemand hier een beter oplossing voor? Lambert ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] fietsen door de Ijtunnel
2008/9/8 Geert Schuring [EMAIL PROTECTED]: Primary zijn tevens de N-wegen die geen autoweg zijn. Althans dit lijkt momenteel de consensus als de wiki daar tenminste een weerslag van is. Ik vind dit onderscheid tussen trunk in primary ongelukkig. Een concreet voorbeeld is de N359 van Bolsward naar Winsum (dat is het stuk van de N359 dat ik ken). Dat zou grotendeels highway=trunk zijn, vanwege de autowegstatus met bijbehorende snelheidslimiet 100kmh. Maar deze weg kent gelijkvloerse kruisingen waar de autowegstatus vervalt. Dat zou leiden tot een andere rendering (trunks zijn groen, primaries rood. Dat lijkt me ongewenst; als we een rendering-standaard willen hebben die in principe wereldwijd moet kunnen worden toegepast - dat vind ik belangrijk - dan kunnen we dus geen alternerende trunk-primary-trunk-prinmary-wegen hebben. Wat mij betreft is trunk een onnodige laag voor Nederland. Dat ben ik niet met je eens. Ten eerste mag rendering nooit een argument zijn om de realiteit anders te taggen dan ze werkelijk is. Het hele idee achter multi layer software design gaat ook hier op. Tags zijn een andere layer dan rendering en routing, en moeten dus losgekoppeld zijn van elkaar. In een ideale wereld, ja. Maar dit is OpenStreetMap en conventies worden niet bedacht, maar ontstaan. Trunks zijn groen en primaries rood en als wij autowegen als trunk en overige N's als primaries gaan taggen, dan ziet de kaart eruit als een lappendeken. In principe ben ik het met je eens! dat rendering nooit een argument zou moeten zijn, maar ik wil wel graag dat als mensen naar openstreetmap.org gaan, ze een mooie wereldkaart te zien krijgen die consistent is en bruiikbaar, en waarvan mensen niet denken: 'wat een gekke kaart, doe mij maar google'. Mensen hebben (op dit moment) nog maar weinig argumenten nodig om af te haken als OSM ze als alternatief wordt geboden. Bovendien is de issue die je noemt helemaal geen probleem... op de hogere zoom niveau's render je trunks en primairies gewoon gezelfde, en op de lagere niveau's render je een mooie overgang tussen 2 licht verschillende wegen. Ziet er prima uit. Dat kun jij doen in je eigen applicatie, we kunnen het op tile.osm.nl doen, maar de rendering op .org zal niet gaan veranderen omdat wij een aantal conventies gaan afspreken. Hier in Ede hebben we ook een voorbeeld waarbij een autoweg een kilometer voor de bebouwde kom veranderd in een primary road, waardoor de snelheid terug gaat naar 80... even verder staan er dan bordjes 70.. en weer iets verder begint de bebouwde kom waardoor het 50 wordt. Autowegen en N-wegen (primary) zijn echt verschillend in nederland, en hebben een verschillende functie. Autowegen zijn een subset van de N-wegen en een weg kan over een afstand van een aantal kilometer een aantal malen van type verschieten, zoals we dus allebei weten. Dit is het technische onderscheid. De classificatie 'Trunk road' is (in GB, waar de term vandaan komt) een administratieve: Er zijn een aantal bij wet aangewezen trunk roads die onder rechtstreekse verantwoordelijkheid vallen van het ministerie van transport. In die zin zouden alle Rijks-N-wegen trunks moeten zijn en alle provinciale N-wegen primaries. Maar het is de vraag of dat voor de eindgebruiker interessant is; in GB is het begrip 'trunk road' ingebrugerd, in Nederland weet 'niemand' welke N-wegen rijkswegen zijn en welke provinciaal. Zodra we een concept-tagging-standaard hebben, kunnen jullie hierop reageren. Ik reageer nu omdat het onderwerp nu ter sprake komt. Ik waardeer het initiatief voor een tagging-commissie, maar realiseer je dat je de wereld er niet mee gaat veranderen. -- martijn van exel -+- [EMAIL PROTECTED] -+- http://www.schaaltreinen.nl/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] fietsen door de Ijtunnel
2008/9/8 Geert Schuring [EMAIL PROTECTED]: Een autoweg staat echter al vast: dit is een highway=trunk, en krijgt impliciet het volgende mee: maxspeed=100, bicycle=no, foot=no. Impliciet betekend dat deze tags alleen toegevoegd *moeten* worden aan de weg als ze afwijken van de default, ze *mogen* altijd worden toegevoegd. Vanwege argumenten genoemd elders in deze thread vind ik dit geen goede keuze. Trunk is wat mij betreft een onnodige laag en leidt alleen maar tot verwarring en discussie. Zie mijn voorbeeld van de N359. -- martijn van exel -+- [EMAIL PROTECTED] -+- http://www.schaaltreinen.nl/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] fietsen door de Ijtunnel
Primary zijn tevens de N-wegen die geen autoweg zijn. Althans dit lijkt momenteel de consensus als de wiki daar tenminste een weerslag van is. Ik vind dit onderscheid tussen trunk in primary ongelukkig. Een concreet voorbeeld is de N359 van Bolsward naar Winsum (dat is het stuk van de N359 dat ik ken). Dat zou grotendeels highway=trunk zijn, vanwege de autowegstatus met bijbehorende snelheidslimiet 100kmh. Maar deze weg kent gelijkvloerse kruisingen waar de autowegstatus vervalt. Dat zou leiden tot een andere rendering (trunks zijn groen, primaries rood. Dat lijkt me ongewenst; als we een rendering-standaard willen hebben die in principe wereldwijd moet kunnen worden toegepast - dat vind ik belangrijk - dan kunnen we dus geen alternerende trunk-primary-trunk-prinmary-wegen hebben. Wat mij betreft is trunk een onnodige laag voor Nederland. Dat ben ik niet met je eens. Ten eerste mag rendering nooit een argument zijn om de realiteit anders te taggen dan ze werkelijk is. Het hele idee achter multi layer software design gaat ook hier op. Tags zijn een andere layer dan rendering en routing, en moeten dus losgekoppeld zijn van elkaar. Bovendien is de issue die je noemt helemaal geen probleem... op de hogere zoom niveau's render je trunks en primairies gewoon gezelfde, en op de lagere niveau's render je een mooie overgang tussen 2 licht verschillende wegen. Ziet er prima uit. Hier in Ede hebben we ook een voorbeeld waarbij een autoweg een kilometer voor de bebouwde kom veranderd in een primary road, waardoor de snelheid terug gaat naar 80... even verder staan er dan bordjes 70.. en weer iets verder begint de bebouwde kom waardoor het 50 wordt. Autowegen en N-wegen (primary) zijn echt verschillend in nederland, en hebben een verschillende functie. Zodra we een concept-tagging-standaard hebben, kunnen jullie hierop reageren. Geert. Message sent using UebiMiau 2.7.10 ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] fietsen door de Ijtunnel
Primary zijn tevens de N-wegen die geen autoweg zijn. Althans dit lijkt momenteel de consensus als de wiki daar tenminste een weerslag van is. Ik vind dit onderscheid tussen trunk in primary ongelukkig. Een concreet voorbeeld is de N359 van Bolsward naar Winsum (dat is het stuk van de N359 dat ik ken). Dat zou grotendeels highway=trunk zijn, vanwege de autowegstatus met bijbehorende snelheidslimiet 100kmh. Maar deze weg kent gelijkvloerse kruisingen waar de autowegstatus vervalt. Dat zou leiden tot een andere rendering (trunks zijn groen, primaries rood. Dat lijkt me ongewenst; als we een rendering-standaard willen hebben die in principe wereldwijd moet kunnen worden toegepast - dat vind ik belangrijk - dan kunnen we dus geen alternerende trunk-primary-trunk-prinmary-wegen hebben. Wat mij betreft is trunk een onnodige laag voor Nederland. Martijn 2008/9/8 Roeland Douma [EMAIL PROTECTED]: Trunk road is toch hier in nederland gewoon autoweg? http://wiki.openstreetmap.org/index.php/Nl:The_Netherlands_roads_tagging Want primary zijn de wegen door de een stad (Sxxx) ook en daar mag je dan vaak wel weer fietsen. --Roeland On Monday 08 September 2008 10:32:33 Martijn van Exel wrote: Het was volgens mij tot voor kort een trunk road. Ik heb dat veranderd in Primary omdat het begrip 'trunk road' voor de Nederlandse wegenindeling volgens mij geen betekenis heeft. Maar voor autowegen zou dat inderdaad impliciet mogen zijn: geen langzaam verkeer. 2008/9/8 Roeland Douma [EMAIL PROTECTED]: Woeps sorry mijn fout. Is wel een autoweg. Het is nog vroeg he... On Monday 08 September 2008 10:18:44 Roeland Douma wrote: Ijtunnel is ook getagd als highway=motorway, kortom snelweg dus. En daar mag je in Nederland ook niet fietsen. Dus het effect is hetzelfde. We zouden gewoon een lijstje (op de wiki en netjes in xml) moeten hebben (per land) over waar je wel mag fietsen/lopen etc. Volgens mij is er op de wiki al zo'n lijstje kon hem alleen even niet zo snel vinden. Maar dan zouden dit soort dingen sowieso niet mogen. Net als dat je in Nederland niet over een autoweg mag fietsen en in de bebouwde kom eigenlijk overal mag fietsen tenzij anders aangegeven/fietspad beschikbaar is. --Roeland On Monday 08 September 2008 10:09:56 Martijn van Exel wrote: Bij een weg van de categorie 'autoweg' zou dat impliciet moeten zijn volgens mij. Ik weet niet zeker of de IJtunnelweg daaronder valt, de Nieuwe Leeuwarderweg (aan de noordzijde) in het verleden in elk geval wel. http://nl.wikipedia.org/wiki/Autoweg Martijn 2008/9/8 Lambert Carsten [EMAIL PROTECTED]: Hoi, Naar aanleiding van een bericht op de engelse talk lijst van Lambertus over een nieuwe versie van de route planner (dat er zoietsl bestond buiten Duitsland was mij zelfs ontgaan!): http://tile.openstreetmap.nl/~lambertus/routing-world testte ik het even uit en ontdekte dat ik door de ijtunnel in Amsterdam kon fietsen! Niets ten nadele van de route planner. Wat ontzettend gaaf dat dit er eindelijk is. Ik heb snel even bicycle=no en foot=no tags toegevoegd aan de ijtunnel, maar eigenlijk moet er ook zaken als horse=no en agricultural=no bij en wat er verder aan tags verzonnen worden. Weet iemand hier een beter oplossing voor? Lambert ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl -- martijn van exel -+- [EMAIL PROTECTED] -+- http://www.schaaltreinen.nl/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] fietsen door de Ijtunnel
2008/9/8 Geert Schuring [EMAIL PROTECTED]: gt; Dat ben ik niet met je eens. Ten eerste mag rendering nooit een argument gt; zijn om de realiteit anders te taggen dan ze werkelijk is. Het hele idee gt; achter multi layer software design gaat ook hier op. Tags zijn een andere gt; layer dan rendering en routing, en moeten dus losgekoppeld zijn van elkaar. In een ideale wereld, ja. Maar dit is OpenStreetMap en conventies worden niet bedacht, maar ontstaan. Trunks zijn groen en primaries rood en als wij autowegen als trunk en overige N's als primaries gaan taggen, dan ziet de kaart eruit als een lappendeken. Dat is toch echt een denk-fout. Wegen hebben geen kleur, alleen tags. De associatie tussen groen en trunk is nu mischien sterk omdat we nog niet zoveel verschillende views/renders hebben van de kaart, maar in de toekomst zullen dit er honderden worden die allemaal hun eigen kleurtjes gaan verzinnen. Laten we elkaar nu niet gaan betichten van het maken van denkfouten. Ik denk er op mijn manier over en jij op de jouwe, en we hebben allebei recht op onze zienswijze. Die van mij is ingegeven door mijn inmiddels toch aanzienlijke praktijkervaring met OSM, en die dicteert dat de werkelijkheid van OSM niet van bovenaf, maar van onderuit wordt bepaald. Jouw idee voor het instellen van een commissie voor taggingstandaarden kan daar een mooie rol bij spelen, mits je het niet te veel top-down speelt -- iedereen heeft een valide stem in hoe hij vindt dat de metadata er uit zou moeten zien. Een standaardenwerkgroep kan daarin adviseren maar zal zijn legitimering moeten vinden in de acceptatie van de uitkomsten van hun werk door de grotere gemeenschap. Heb je je licht al opgestoken bij de buurlanden? Hoe gaat het daar? Met name Duitsland is een interessante om naar te kijken vanwege hun sterk regionaal georienteerde organisatie. Ik vind trouwens dat de kaart er nu juist uitziet als een lappen-deken. Verschllende gelijkwaardige wegen hebben verschillende kleuren, terwijl totaal verschillende wegen hetzelfde eruitzien. Ik ben benieuwd of je daarvan een aantal concrete voorbeelden kunt geven. Mijn impressie is namelijk dat het er allemaal wel behoorlijk goed uitziet. En bedenk wat je bedoelt te zeggen met 'gelijkwaardig' - administratief? wegprofiel? snelheidsbeperkingen? In principe ben ik het met je eens! dat rendering nooit een argument zou moeten zijn, maar ik wil wel graag dat als mensen naar openstreetmap.org gaan, ze een mooie wereldkaart te zien krijgen die consistent is en bruiikbaar, en waarvan mensen niet denken: 'wat een gekke kaart, doe mij maar google'. Mensen hebben (op dit moment) nog maar weinig argumenten nodig om af te haken als OSM ze als alternatief wordt geboden. Nogmaals, de huidige rendering op osm.org is naar mijn mening vrij belabberd. De beste manier om hier wat aan te veranderen is door een betere rendering voor te stellen. De Style Editor van PanMan kan je daarmee op weg helpen. gt; gt; Bovendien is de issue die je noemt helemaal geen probleem... op de hogere gt; zoom niveau's render je trunks en primairies gewoon gezelfde, en op de gt; lagere niveau's render je een mooie overgang tussen 2 licht verschillende gt; wegen. Ziet er prima uit. Dat kun jij doen in je eigen applicatie, we kunnen het op tile.osm.nl doen, maar de rendering op .org zal niet gaan veranderen omdat wij een aantal conventies gaan afspreken. Dus jij tagt alles wat je doet zodanig dat het er op osm.org mooi uitziet? En wat nou als de rendering daar wordt aangepast? Nou doe je toch geen recht aan mijn werk, maar inderdaad: ik houd er wel rekening mee. De huidige rendering is natuurlijk niet helemaal uit de lucht komen vallen maar is ontworpen uit de onstane conventies wat betreft de tagging van wegen. Deze is bijzonder UK-biased, omdat het project daar nu eenmaal van de grond is gekomen. Dat moet je in je achterhoofd houden als je de 'geaccepteerde' tags wilt vertalen naar de lokale situatie. Vandaar ook mijn uitwijding over wat trunk roads nou eigenlijk zijn, in een vorige mail. Ik denk dat je dicht bij die oorspronkelijke betekenis moet blijven; en dan kom ik tot mijn conclusie dat deze voor Nederland niet zoveel praktische betekenis heeft. -- martijn van exel -+- [EMAIL PROTECTED] -+- http://www.schaaltreinen.nl/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] fietsen door de Ijtunnel
Ook op de talk list (in het openstreetmap routing service draadje) is een discussie over wat wel en niet per default toegestaan is op de verschillende wegtypes (welke ook weer verschillen per land). Deze default eigenschappen zouden dan niet getagd hoeven te worden, afwijkingen daarentegen expliciet wel. Een lijst met (voor routering belangrijke) default wegeigenschappen is hier: http://wiki.openstreetmap.org/index.php/OSM_tags_for_routing/Access-Restrictions http://wiki.openstreetmap.org/index.php/OSM_tags_for_routing/Maxspeed Access restriction zijn overigens universeel toepasbaar op alle type wegen, dus bijv. hgv=no kun je op welke weg toepassen. Lambert Carsten wrote: On Monday 08 September 2008 10:09:56 Martijn van Exel wrote: Bij een weg van de categorie 'autoweg' zou dat impliciet moeten zijn volgens mij. Ik weet niet zeker of de IJtunnelweg daaronder valt, de Nieuwe Leeuwarderweg (aan de noordzijde) in het verleden in elk geval wel. http://nl.wikipedia.org/wiki/Autoweg Volgens mij is de Ijtunnel een 'autoweg'. Ik denk dat die ook juist getagged is met 'primary'. Ik kan alleen geen impliciete 'access restrictions' vinden die bij primary hoort. Vreemd dat dat er niet (lijken?) te bestaan. Op de discussie tab bij motorway wordt hier wel over gesproken (http://wiki.openstreetmap.org/index.php/Talk:Tag:highway=motorway). Waarschijnlijk moet er op dit punt nog wat werk verzet worden. Misschien iets voor de Werkgroep Tagging Standard van Geert Schuring. Het zal mij echter helaas op korte termijn niet lukken daarin bij te dragen. Lambert ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] fietsen door de Ijtunnel
On Monday 08 September 2008 10:36:46 Roeland Douma wrote: Trunk road is toch hier in nederland gewoon autoweg? http://wiki.openstreetmap.org/index.php/Nl:The_Netherlands_roads_tagging Want primary zijn de wegen door de een stad (Sxxx) ook en daar mag je dan vaak wel weer fietsen. Om de ijtunnel een trunk tag te geven is wel wat voor te zeggen. Het probleem is echter volgens mij dat er op dit moment voor elk type weg een lijst 'implied access restrictions' niet (lijkt?) te bestaan. Als mapper kun je dan ervoor kiezen een weg te taggen op basis van de restricties van de weg ofwel de classificatie door de overheid (wegnummering Axx, Sxx enz.) te volgen en indien nodig access tags toe te voegen On Monday 08 September 2008 11:11:16 Geert Schuring wrote: Precies. De werkgroep Tagging standaard heeft de 12e een meeting bij mij thuis waar we beginnen met het opstellen van een standaard voor autowegen, inclusief alle impliciete en expliciete tags die daarbij horen. Hartstikke mooi! Een autoweg staat echter al vast: dit is een highway=trunk, en krijgt impliciet het volgende mee: maxspeed=100, bicycle=no, foot=no. Impliciet betekend dat deze tags alleen toegevoegd *moeten* worden aan de weg als ze afwijken van de default, ze *mogen* altijd worden toegevoegd. Te overwegen valt om voor de belangrijke hoofdwegen (motorway, trunk en eventueel primary) de boel om te draaien en dus als impliciete tags access=no, motorcar=yes enz. te nemen Mogelijk dat je daarmee voorkomt dat nieuwe tags (segway, golfcart...) niet impliciet ineens de snelweg op mogen. Uiteraard kan de lijst met impliciete verboden worden steeds worden bijgewerkt, maar wij weten inmiddels dat een systeem van eerst alles toestaan en later de boel dicht gooien als er iets niet goed gaat, in de praktijk voortdurend voor problemen zorgt. De werkgroep beperkt zich in eerste instantie tot standaarden voor auto's, fietsers en wandelaars. Pas wanneer deze standaarden volledig uitgewerkt zijn zullen standaarden voor vrachtverkeer, motoren, noodhulpverleners en andere veel voorkomende vormen van verkeer worden vastgelegd. Je moet ergens beginnen! Lambert ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] fietsen door de Ijtunnel
Ik ben het met je eens dat het geen 1:1 mapping is. Maar een autoweg is toch echt significant anders dan een een primary road. Zo mogen op primary roads in veel gevallen best fietsers e.d. terwijl op autowegen je minimaal 50km/u moet kunnen rijden. Dus qua rendering is het misschien minder mooi maar het mappen is daardoor wel een stuk toegangkelijker aangezien iedereen in Nederland het begrip autoweg wel kent. Je hebt gelijk dat ze op op osm.org niet anders zullen renderen. Maar het geeft wel een goed beeld van de kaart. Zo is een autoweg meer bedoeld voor de verplaatsing van het verkeer dan een primary road daar in de buurt. En dit verschil valt geheel weg als ze ook als primary getagd worden. En hoewel dat nu nog niet het geval is is het de bedoeling dat alle autowegen gescheiden rijbanen krijgen (echter dit kan nog wel even duren). De doorsnede van de eigenschappen van een primary-road en een autoweg zijn dus inderdaad wel groot. Maar ik denk dat er te veel verschillen zijn om te zeggen dat een autoweg een subset is van een primary road. --Roeland On Monday 08 September 2008 12:17:48 Martijn van Exel wrote: 2008/9/8 Geert Schuring [EMAIL PROTECTED]: Primary zijn tevens de N-wegen die geen autoweg zijn. Althans dit lijkt momenteel de consensus als de wiki daar tenminste een weerslag van is. Ik vind dit onderscheid tussen trunk in primary ongelukkig. Een concreet voorbeeld is de N359 van Bolsward naar Winsum (dat is het stuk van de N359 dat ik ken). Dat zou grotendeels highway=trunk zijn, vanwege de autowegstatus met bijbehorende snelheidslimiet 100kmh. Maar deze weg kent gelijkvloerse kruisingen waar de autowegstatus vervalt. Dat zou leiden tot een andere rendering (trunks zijn groen, primaries rood. Dat lijkt me ongewenst; als we een rendering-standaard willen hebben die in principe wereldwijd moet kunnen worden toegepast - dat vind ik belangrijk - dan kunnen we dus geen alternerende trunk-primary-trunk-prinmary-wegen hebben. Wat mij betreft is trunk een onnodige laag voor Nederland. Dat ben ik niet met je eens. Ten eerste mag rendering nooit een argument zijn om de realiteit anders te taggen dan ze werkelijk is. Het hele idee achter multi layer software design gaat ook hier op. Tags zijn een andere layer dan rendering en routing, en moeten dus losgekoppeld zijn van elkaar. In een ideale wereld, ja. Maar dit is OpenStreetMap en conventies worden niet bedacht, maar ontstaan. Trunks zijn groen en primaries rood en als wij autowegen als trunk en overige N's als primaries gaan taggen, dan ziet de kaart eruit als een lappendeken. In principe ben ik het met je eens! dat rendering nooit een argument zou moeten zijn, maar ik wil wel graag dat als mensen naar openstreetmap.org gaan, ze een mooie wereldkaart te zien krijgen die consistent is en bruiikbaar, en waarvan mensen niet denken: 'wat een gekke kaart, doe mij maar google'. Mensen hebben (op dit moment) nog maar weinig argumenten nodig om af te haken als OSM ze als alternatief wordt geboden. Bovendien is de issue die je noemt helemaal geen probleem... op de hogere zoom niveau's render je trunks en primairies gewoon gezelfde, en op de lagere niveau's render je een mooie overgang tussen 2 licht verschillende wegen. Ziet er prima uit. Dat kun jij doen in je eigen applicatie, we kunnen het op tile.osm.nl doen, maar de rendering op .org zal niet gaan veranderen omdat wij een aantal conventies gaan afspreken. Hier in Ede hebben we ook een voorbeeld waarbij een autoweg een kilometer voor de bebouwde kom veranderd in een primary road, waardoor de snelheid terug gaat naar 80... even verder staan er dan bordjes 70.. en weer iets verder begint de bebouwde kom waardoor het 50 wordt. Autowegen en N-wegen (primary) zijn echt verschillend in nederland, en hebben een verschillende functie. Autowegen zijn een subset van de N-wegen en een weg kan over een afstand van een aantal kilometer een aantal malen van type verschieten, zoals we dus allebei weten. Dit is het technische onderscheid. De classificatie 'Trunk road' is (in GB, waar de term vandaan komt) een administratieve: Er zijn een aantal bij wet aangewezen trunk roads die onder rechtstreekse verantwoordelijkheid vallen van het ministerie van transport. In die zin zouden alle Rijks-N-wegen trunks moeten zijn en alle provinciale N-wegen primaries. Maar het is de vraag of dat voor de eindgebruiker interessant is; in GB is het begrip 'trunk road' ingebrugerd, in Nederland weet 'niemand' welke N-wegen rijkswegen zijn en welke provinciaal. Zodra we een concept-tagging-standaard hebben, kunnen jullie hierop reageren. Ik reageer nu omdat het onderwerp nu ter sprake komt. Ik waardeer het initiatief voor een tagging-commissie, maar realiseer je dat je de wereld er niet mee gaat veranderen. ___ Talk-nl mailing list Talk-nl@openstreetmap.org
Re: [OSM-talk-nl] fietsen door de Ijtunnel
Ik weet wat je bedoelt. Ik heb ook een weg hier in de buurt die Autoweg is maar wel gelijkvloerse kruisingen heeft. Echter voor elk kruispunt staan dan ook bordjes einde autoweg en daarna weer begin autoweg. Dus technisch gezien is is het wel een representatie van de werkelijkheid. Als je namelijk geen apparte highway= tag hebt voor autoweg dan moet je aan primary wegen allemaal metadata gaan toevoegen. En hou je hetzelfde probleem. Daar die metadata verandert op het moment dat je bij een gelijkvloerse kruising komt. Het enige wat je dan niet hebt is dat het kleurtje gelijkt blijft. Maar dit zou je ook gewoon in de stylefiles kunnen laten doen. --Roeland On Monday 08 September 2008 11:19:17 Martijn van Exel wrote: Primary zijn tevens de N-wegen die geen autoweg zijn. Althans dit lijkt momenteel de consensus als de wiki daar tenminste een weerslag van is. Ik vind dit onderscheid tussen trunk in primary ongelukkig. Een concreet voorbeeld is de N359 van Bolsward naar Winsum (dat is het stuk van de N359 dat ik ken). Dat zou grotendeels highway=trunk zijn, vanwege de autowegstatus met bijbehorende snelheidslimiet 100kmh. Maar deze weg kent gelijkvloerse kruisingen waar de autowegstatus vervalt. Dat zou leiden tot een andere rendering (trunks zijn groen, primaries rood. Dat lijkt me ongewenst; als we een rendering-standaard willen hebben die in principe wereldwijd moet kunnen worden toegepast - dat vind ik belangrijk - dan kunnen we dus geen alternerende trunk-primary-trunk-prinmary-wegen hebben. Wat mij betreft is trunk een onnodige laag voor Nederland. Martijn 2008/9/8 Roeland Douma [EMAIL PROTECTED]: Trunk road is toch hier in nederland gewoon autoweg? http://wiki.openstreetmap.org/index.php/Nl:The_Netherlands_roads_tagging Want primary zijn de wegen door de een stad (Sxxx) ook en daar mag je dan vaak wel weer fietsen. --Roeland On Monday 08 September 2008 10:32:33 Martijn van Exel wrote: Het was volgens mij tot voor kort een trunk road. Ik heb dat veranderd in Primary omdat het begrip 'trunk road' voor de Nederlandse wegenindeling volgens mij geen betekenis heeft. Maar voor autowegen zou dat inderdaad impliciet mogen zijn: geen langzaam verkeer. 2008/9/8 Roeland Douma [EMAIL PROTECTED]: Woeps sorry mijn fout. Is wel een autoweg. Het is nog vroeg he... On Monday 08 September 2008 10:18:44 Roeland Douma wrote: Ijtunnel is ook getagd als highway=motorway, kortom snelweg dus. En daar mag je in Nederland ook niet fietsen. Dus het effect is hetzelfde. We zouden gewoon een lijstje (op de wiki en netjes in xml) moeten hebben (per land) over waar je wel mag fietsen/lopen etc. Volgens mij is er op de wiki al zo'n lijstje kon hem alleen even niet zo snel vinden. Maar dan zouden dit soort dingen sowieso niet mogen. Net als dat je in Nederland niet over een autoweg mag fietsen en in de bebouwde kom eigenlijk overal mag fietsen tenzij anders aangegeven/fietspad beschikbaar is. --Roeland On Monday 08 September 2008 10:09:56 Martijn van Exel wrote: Bij een weg van de categorie 'autoweg' zou dat impliciet moeten zijn volgens mij. Ik weet niet zeker of de IJtunnelweg daaronder valt, de Nieuwe Leeuwarderweg (aan de noordzijde) in het verleden in elk geval wel. http://nl.wikipedia.org/wiki/Autoweg Martijn 2008/9/8 Lambert Carsten [EMAIL PROTECTED]: Hoi, Naar aanleiding van een bericht op de engelse talk lijst van Lambertus over een nieuwe versie van de route planner (dat er zoietsl bestond buiten Duitsland was mij zelfs ontgaan!): http://tile.openstreetmap.nl/~lambertus/routing-world testte ik het even uit en ontdekte dat ik door de ijtunnel in Amsterdam kon fietsen! Niets ten nadele van de route planner. Wat ontzettend gaaf dat dit er eindelijk is. Ik heb snel even bicycle=no en foot=no tags toegevoegd aan de ijtunnel, maar eigenlijk moet er ook zaken als horse=no en agricultural=no bij en wat er verder aan tags verzonnen worden. Weet iemand hier een beter oplossing voor? Lambert ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] fietsen door de Ijtunnel
Ik vind het juist hartstikke mooi dat ze groen gerenderd worden. Dat is namelijk precies de kleur van de baan die straks op elke 100 km/h weg in nederland tussen de twee doorgestrokken strepen zal staan. In de kop van Noord-Holland, waar bijna geen snelwegwegen zijn, zijn dit toch echt de belangrijkste verkeersaders. Mocht je ze nog niet gezien hebben in de buurt, meer info op: http://www.rijkswaterstaat.nl/vraagenantwoord/#v194625 Groet, Floris Roeland Douma schreef: Ik ben het met je eens dat het geen 1:1 mapping is. Maar een autoweg is toch echt significant anders dan een een primary road. Zo mogen op primary roads in veel gevallen best fietsers e.d. terwijl op autowegen je minimaal 50km/u moet kunnen rijden. Dus qua rendering is het misschien minder mooi maar het mappen is daardoor wel een stuk toegangkelijker aangezien iedereen in Nederland het begrip autoweg wel kent. Je hebt gelijk dat ze op op osm.org niet anders zullen renderen. Maar het geeft wel een goed beeld van de kaart. Zo is een autoweg meer bedoeld voor de verplaatsing van het verkeer dan een primary road daar in de buurt. En dit verschil valt geheel weg als ze ook als primary getagd worden. En hoewel dat nu nog niet het geval is is het de bedoeling dat alle autowegen gescheiden rijbanen krijgen (echter dit kan nog wel even duren). De doorsnede van de eigenschappen van een primary-road en een autoweg zijn dus inderdaad wel groot. Maar ik denk dat er te veel verschillen zijn om te zeggen dat een autoweg een subset is van een primary road. --Roeland On Monday 08 September 2008 12:17:48 Martijn van Exel wrote: 2008/9/8 Geert Schuring [EMAIL PROTECTED]: Primary zijn tevens de N-wegen die geen autoweg zijn. Althans dit lijkt momenteel de consensus als de wiki daar tenminste een weerslag van is. Ik vind dit onderscheid tussen trunk in primary ongelukkig. Een concreet voorbeeld is de N359 van Bolsward naar Winsum (dat is het stuk van de N359 dat ik ken). Dat zou grotendeels highway=trunk zijn, vanwege de autowegstatus met bijbehorende snelheidslimiet 100kmh. Maar deze weg kent gelijkvloerse kruisingen waar de autowegstatus vervalt. Dat zou leiden tot een andere rendering (trunks zijn groen, primaries rood. Dat lijkt me ongewenst; als we een rendering-standaard willen hebben die in principe wereldwijd moet kunnen worden toegepast - dat vind ik belangrijk - dan kunnen we dus geen alternerende trunk-primary-trunk-prinmary-wegen hebben. Wat mij betreft is trunk een onnodige laag voor Nederland. Dat ben ik niet met je eens. Ten eerste mag rendering nooit een argument zijn om de realiteit anders te taggen dan ze werkelijk is. Het hele idee achter multi layer software design gaat ook hier op. Tags zijn een andere layer dan rendering en routing, en moeten dus losgekoppeld zijn van elkaar. In een ideale wereld, ja. Maar dit is OpenStreetMap en conventies worden niet bedacht, maar ontstaan. Trunks zijn groen en primaries rood en als wij autowegen als trunk en overige N's als primaries gaan taggen, dan ziet de kaart eruit als een lappendeken. In principe ben ik het met je eens! dat rendering nooit een argument zou moeten zijn, maar ik wil wel graag dat als mensen naar openstreetmap.org gaan, ze een mooie wereldkaart te zien krijgen die consistent is en bruiikbaar, en waarvan mensen niet denken: 'wat een gekke kaart, doe mij maar google'. Mensen hebben (op dit moment) nog maar weinig argumenten nodig om af te haken als OSM ze als alternatief wordt geboden. Bovendien is de issue die je noemt helemaal geen probleem... op de hogere zoom niveau's render je trunks en primairies gewoon gezelfde, en op de lagere niveau's render je een mooie overgang tussen 2 licht verschillende wegen. Ziet er prima uit. Dat kun jij doen in je eigen applicatie, we kunnen het op tile.osm.nl doen, maar de rendering op .org zal niet gaan veranderen omdat wij een aantal conventies gaan afspreken. Hier in Ede hebben we ook een voorbeeld waarbij een autoweg een kilometer voor de bebouwde kom veranderd in een primary road, waardoor de snelheid terug gaat naar 80... even verder staan er dan bordjes 70.. en weer iets verder begint de bebouwde kom waardoor het 50 wordt. Autowegen en N-wegen (primary) zijn echt verschillend in nederland, en hebben een verschillende functie. Autowegen zijn een subset van de N-wegen en een weg kan over een afstand van een aantal kilometer een aantal malen van type verschieten, zoals we dus allebei weten. Dit is het technische onderscheid. De classificatie 'Trunk road' is (in GB, waar de term vandaan komt) een administratieve: Er zijn een aantal bij wet aangewezen trunk roads die onder rechtstreekse verantwoordelijkheid vallen van het ministerie van transport. In die zin zouden alle Rijks-N-wegen trunks moeten zijn en alle provinciale N-wegen primaries. Maar het is de vraag of dat voor de eindgebruiker interessant is; in GB
Re: [OSM-talk-nl] fietsen door de Ijtunnel
Op 8 september 2008 15:14 schreef Floris Looijesteijn [EMAIL PROTECTED] het volgende: Ik vind het juist hartstikke mooi dat ze groen gerenderd worden. Dat is namelijk precies de kleur van de baan die straks op elke 100 km/h weg in nederland tussen de twee doorgestrokken strepen zal staan. In de kop van Noord-Holland, waar bijna geen snelwegwegen zijn, zijn dit toch echt de belangrijkste verkeersaders. Mocht je ze nog niet gezien hebben in de buurt, meer info op: http://www.rijkswaterstaat.nl/vraagenantwoord/#v194625 ja die dingen heb ik 2 jaar geleden al bij motor theorie moeten leren ;) maar je ziet ze nog weinig ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] fietsen door de Ijtunnel
In Friesland heb ik ze al best veel gezien. Erg fraai en duidelijk, ook in het donker. 2008/9/8 Rob [EMAIL PROTECTED]: Op 8 september 2008 15:14 schreef Floris Looijesteijn [EMAIL PROTECTED] het volgende: Ik vind het juist hartstikke mooi dat ze groen gerenderd worden. Dat is namelijk precies de kleur van de baan die straks op elke 100 km/h weg in nederland tussen de twee doorgestrokken strepen zal staan. In de kop van Noord-Holland, waar bijna geen snelwegwegen zijn, zijn dit toch echt de belangrijkste verkeersaders. Mocht je ze nog niet gezien hebben in de buurt, meer info op: http://www.rijkswaterstaat.nl/vraagenantwoord/#v194625 ja die dingen heb ik 2 jaar geleden al bij motor theorie moeten leren ;) maar je ziet ze nog weinig ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl -- martijn van exel -+- [EMAIL PROTECTED] -+- http://www.schaaltreinen.nl/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] fietsen door de Ijtunnel
Op 8 september 2008 15:26 schreef Martijn van Exel [EMAIL PROTECTED] het volgende: In Friesland heb ik ze al best veel gezien. Erg fraai en duidelijk, ook in het donker. volgens mij was er ook nog zoiets dat ze de max snelheid aangaven 80/100, de combinatie van groen en witte strepen http://auto-en-vervoer.infonu.nl/diversen/16551-nederlandse-wegen-herkenning-en-belijning.html ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] open communities drink @ picnic
Uit de ISOC mailinglist: === En natuurlijk ben je - kaartje of niet - van harte welkom bij de open communities drink op donderdag 25 september 2008 vanaf 17.00 uur. Naast Internet Society Nederland zullen onder meer Open-CI, OpenDoc Society, Gridforum.nl, OpenDomein, nl.OpenOffice.org en NLnet acte de presence geven. Lokatie: Westergasterras, Amsterdam. Gratis toegankelijk. Meer info: http://www.picnicnetwork.org/page/24486/en Met vriendelijke groet, Internet Society Nederland === (op de site staat Wibautstraat 150, 1091 GR Amsterdam als locatie) ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] fietsen door de Ijtunnel
2008/9/8 Roeland Douma [EMAIL PROTECTED]: Ik ben het met je eens dat het geen 1:1 mapping is. Maar een autoweg is toch echt significant anders dan een een primary road. Zo mogen op primary roads in veel gevallen best fietsers e.d. terwijl op autowegen je minimaal 50km/u moet kunnen rijden. Dus qua rendering is het misschien minder mooi maar het mappen is daardoor wel een stuk toegangkelijker aangezien iedereen in Nederland het begrip autoweg wel kent. Je moet eerst beslissen wat je onder een Primary verstaat, voordat je er eigenschappen aan kan toedichten. De term 'primary' als OSM-tag heeft een sterke band met het UK-begrip 'primary route' en dat is een administratief begrip, niet een verkeerskundig. In de UK is het ondubbelzinnig duidelijk welke wegen er getagd moeten worden als 'primary' en welke als 'Trunk'. Hier is het onderscheid anders want tweeledig: er is een administratief (rijksweg, provinciale weg of lokale weg) en een verkeerskundig onderscheid (snelheidslimiet, toegelaten verkeer, rijbaanscheiding, ...). Ik denk dat het zuiver administratieve onderscheid (wie is verantwoordelijk voor aanleg en onderhoud) voor Nederland veel minder relevant is, domweg omdat het voor de gebruiker geen zichtbaar onderscheid is. Wat waarneembaar is, is het volgende (kort door de bocht): * Er zijn A-wegen, N-wegen, en ongenummerde wegen. * Er zijn wegen waarop langzaam verkeer niet toegelaten is en waar geen gelijkvloerse kruisingen zijn - dit zijn de Autowegen en de Autosnelwegen, en er zijn wegen waarop die beperkingen niet gelden (de overige wegen). Deze twee onderscheiden lopen dwars door elkaar, waardoor er verwarring ontstaat.En verwarring leidt tot inconsistente tagging door de mappers. Dus als een tagging-standaardenclub daar duidelijkheid in kan helpen aanbrengen door het doen van een aanbeveling van een ondubbelzinnig (dus niet: wijkontsluitingsweg = secondary, daar moet namelijk nog een interpretatieslag tussen) schema, dan juich ik dat toe. Alleen het introduceren van een geheel nieuwe interpretatie van 'trunk roads' vind ik niet zo'n goed idee, en dat wilde ik graag ventileren. Hoewel ik ook wel de voordelen zie van het taggen van autowegen als 'trunk roads', denk ik dat het ook problemen gaat opleveren. Ik ben benieuwd naar de consensus die gaat ontstaan. BTW, ik kijk nog eens naar de concurrenten, leuk voor een referentiekader: * Google Maps rendert voor de UK gewoonweg een niveau meer dan voor Nederland. Dit levert voor de UK een heel ander kaartbeeld op dan voor NL. * Yahoo maps doet het eveneens zo. * Michelin rendert trunk roads niet als afzonderlijk type, waardoor de kaart een uniforme verschijning heeft over Europa. * MS Live Maps rendert trunk roads eveneens niet in een afzonderlijke kleur. Je hebt gelijk dat ze op op osm.org niet anders zullen renderen. Maar het geeft wel een goed beeld van de kaart. Zo is een autoweg meer bedoeld voor de verplaatsing van het verkeer dan een primary road daar in de buurt. En dit verschil valt geheel weg als ze ook als primary getagd worden. En hoewel dat nu nog niet het geval is is het de bedoeling dat alle autowegen gescheiden rijbanen krijgen (echter dit kan nog wel even duren). Dit kan ik met al mijn vervoersplanologische achtergrond nergens uit mijn herinnering opgraven, maar ik laat me hier graag overtuigen door een link naar een Rijkswegenplan of een Meerjarenprogramma waarin zulks is gesteld :) De doorsnede van de eigenschappen van een primary-road en een autoweg zijn dus inderdaad wel groot. Maar ik denk dat er te veel verschillen zijn om te zeggen dat een autoweg een subset is van een primary road. Dat zei ik dan ook niet ;) -- martijn van exel -+- [EMAIL PROTECTED] -+- http://www.schaaltreinen.nl/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] fietsen door de IJtunnel
Hee, een interessant discussie :-p Zoals jullie misschien weten ben ik eerder voorstander van autoweg=trunk geweest. Alhoewel Martijn's voorbeeld van de N359 erg vervelend klinkt, zou ik toch zeggen dat je in dat geval gewoon de hele weg trunk maakt en aan de niet-autoweg-stukjes aparte tags hangt (wat is er anders op de kruising, snelheid?). Zie ook verderop. On Monday 08 September 2008, Martijn van Exel wrote: [...] Jouw idee voor het instellen van een commissie voor taggingstandaarden kan daar een mooie rol bij spelen, mits je het niet te veel top-down speelt -- iedereen heeft een valide stem in hoe hij vindt dat de metadata er uit zou moeten zien. Mijns inziens moet de werkgroep vooral verduidelijking brengen en misschien zelfs opmerkingen voor speciale doelgroepen toevoegen in de opgeleverde documenten. (Daar moeten we het ook over hebben: voor welke doelgroep gaan we de standaarden opstellen?). Bij die opmerkingen denk ik dan bijvoorbeeld aan informatie over zaken waar nog geen consensus over bestaat. Een standaardenwerkgroep kan daarin adviseren maar zal zijn legitimering moeten vinden in de acceptatie van de uitkomsten van hun werk door de grotere gemeenschap. Advisering zou ik ook een mogelijk doel kunnen zijn, goed idee. [...] De huidige rendering is natuurlijk niet helemaal uit de lucht komen vallen maar is ontworpen uit de onstane conventies wat betreft de tagging van wegen. Deze is bijzonder UK-biased, omdat het project daar nu eenmaal van de grond is gekomen. Dat moet je in je achterhoofd houden als je de 'geaccepteerde' tags wilt vertalen naar de lokale situatie. Vandaar ook mijn uitwijding over wat trunk roads nou eigenlijk zijn, in een vorige mail. Ik denk dat je dicht bij die oorspronkelijke betekenis moet blijven; en dan kom ik tot mijn conclusie dat deze voor Nederland niet zoveel praktische betekenis heeft. Mmm, oorspronkelijke betekenis... wij hebben helemaal geen trunk, primary, secondary, tertiary of unclassified wegen. We hebben iets met N-nummers en doorgaande wegen en verder is het een beetje zooitje vergeleken met de UK (zo lijkt het mij in ieder geval). Ik zou het jammer vinden als we een weg waarvan het concept zo mooi overeen komt met trunk, namelijk net wat minder dan een snelweg, maar meer dan een gewone doorgaande weg, niet zouden taggen als trunk. -- Freek ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] fietsen door de IJtunnel
2008/9/8 Freek [EMAIL PROTECTED]: Hee, een interessant discussie :-p Zoals jullie misschien weten ben ik eerder voorstander van autoweg=trunk geweest. Alhoewel Martijn's voorbeeld van de N359 erg vervelend klinkt, zou ik toch zeggen dat je in dat geval gewoon de hele weg trunk maakt en aan de niet-autoweg-stukjes aparte tags hangt (wat is er anders op de kruising, snelheid?). Zie ook verderop. Al denkende en lezende (vooral http://auto-en-vervoer.infonu.nl/diversen/16551-nederlandse-wegen-herkenning-en-belijning.html is nuttig hier) kom neig ik ook meer naar een vorm van extra gelaagdheid. In mijn redenering ga ik te veel uit van het 'ondeelbare' N-wegen-systeem, terwijl daar steeds meer verfijning in wordt aangebracht, en deze verfijning ook steeds zichtbaarder wordt door onderscheidende belijning. -- martijn van exel -+- [EMAIL PROTECTED] -+- http://www.schaaltreinen.nl/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] fietsen door de Ijtunnel
Martijn van Exel wrote: Deze twee onderscheiden lopen dwars door elkaar, waardoor er verwarring ontstaat.En verwarring leidt tot inconsistente tagging door de mappers. Dus als een tagging-standaardenclub daar duidelijkheid in kan helpen aanbrengen door het doen van een aanbeveling van een ondubbelzinnig (dus niet: wijkontsluitingsweg = secondary, daar moet namelijk nog een interpretatieslag tussen) schema, dan juich ik dat toe. Alleen het introduceren van een geheel nieuwe interpretatie van 'trunk roads' vind ik niet zo'n goed idee, en dat wilde ik graag ventileren. Hoewel ik ook wel de voordelen zie van het taggen van autowegen als 'trunk roads', denk ik dat het ook problemen gaat opleveren. Ik ben benieuwd naar de consensus die gaat ontstaan. Ik vind dat je een heel goed punt maakt. Ik wil in dit verband ook deze weg even laten zien: http://informationfreeway.org/?lat=51.33lon=6.04zoom=14layers=B000F000F De Baarlosweg die overgaat in De Meern. Getagt (uit de AND data) als een secondary, maar in de praktijk een bochtig weggetje dat door de wegbeheerder (terecht) op 60 km/h is gezet. Is dat een secondary waard, vooral als ik dat vergelijk met de N562 (brede 80 km weg met vrijliggende fietspaden) die ook als secondary getagt is? Maarten ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] fietsen door de Ijtunnel
Rob wrote: ja die dingen heb ik 2 jaar geleden al bij motor theorie moeten leren ;) maar je ziet ze nog weinig Kom hier eens langs, in de provincie waar ze altijd haantje-de-voorste moeten spelen met verkeersnieuwigheden. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] fietsen door de Ijtunnel
Martijn van Exel wrote: voor de gebruiker geen zichtbaar onderscheid is. Wat waarneembaar is, is het volgende (kort door de bocht): * Er zijn A-wegen, N-wegen, en ongenummerde wegen. S-wegen (en de discussie een klein beetje oprekkend naar de zuiderburen, waar de situatie qua tagging nog iets onduidelijker is: R-wegen) * Er zijn wegen waarop langzaam verkeer niet toegelaten is en waar geen gelijkvloerse kruisingen zijn - dit zijn de Autowegen en de Autosnelwegen, en er zijn wegen waarop die beperkingen niet gelden (de overige wegen). Een autoweg is niet per definitie zonder gelijkvloerse kruisingen, en er zal nog heel wat water door de Rijn lopen vooraleer dat in de praktijk wel zo zal zijn. Van de eerder aangehaalde voorbeelden van een 1+1 autoweg zonder middenbermscheiding en met gelijkvloerse kruisingen liggen er in mijn regio nog genoeg. Sterker, in een regio waar geen enkele snelweg ligt, mag de functie en importantie van deze 1+1 autowegen niet onderschat worden. Vandaar dat ik deze discussie met belangstelling volg. Deze twee onderscheiden lopen dwars door elkaar, waardoor er verwarring ontstaat.En verwarring leidt tot inconsistente tagging door de mappers. Dus als een tagging-standaardenclub daar duidelijkheid in Ik heb de 1+1 autowegen in mijn regio tot nu toe niet aangeraakt, zodat ze vanuit AND nog primary waren, maar iemand heeft er nu van 1 al trunk gemaakt, inclusief de kruispunten, waar *geen* autoweg-statuut geldt. Eindelijk duidelijkheid voor de mappers zou inderdaad welkom zijn. kan helpen aanbrengen door het doen van een aanbeveling van een ondubbelzinnig (dus niet: wijkontsluitingsweg = secondary, daar moet namelijk nog een interpretatieslag tussen) schema, dan juich ik dat Komt nog bij dat de 'Duurzaam Veilig' (DV) begrippen zoals Erftoegangsweg (ETW), Gebiedsontsluitingsweg (GOW) en Stroomweg (SW) niet simpel zijn uit te leggen, en daardoor zelfs door verschillende overheden niet consistent zijn toegepast. Ik noem maar een voorbeeld van een GOW met SW-belijning, of een mix van DV-belijning met RONA-belijning. Het maakt het er ook voor de weggebruiker niet duidelijker op. toe. Alleen het introduceren van een geheel nieuwe interpretatie van 'trunk roads' vind ik niet zo'n goed idee, en dat wilde ik graag ventileren. Hoewel ik ook wel de voordelen zie van het taggen van autowegen als 'trunk roads', denk ik dat het ook problemen gaat opleveren. Ik ben benieuwd naar de consensus die gaat ontstaan. Je zou deze tags ook los kunnen zien van de ontstaansgeschiedenis, en ze alleen kunnen zien als 'niveaus' van tagging van wegen. Dan hoef je ook geen discussie te houden over het woordje 'trunk', en ook geen nieuwe tags uit te vinden alleen voor onze autoweg. BTW, ik kijk nog eens naar de concurrenten, leuk voor een referentiekader: * Google Maps rendert voor de UK gewoonweg een niveau meer dan voor Nederland. Dit levert voor de UK een heel ander kaartbeeld op dan voor NL. Het kaartbeeld is ook al anders doordat het kleurgebruik daar anders is. Ze gebruiken (net als OSM) blauw/groen voor motorway/trunk, terwijl de autosnelwegen in NL dus niet blauw zijn, en autowegen soms gerenderd worden als autosnelweg, en soms als normale (niet autoweg) N-weg (en ik kan zo niet ontdekken wat daarin de criteria zijn) * Michelin rendert trunk roads niet als afzonderlijk type, waardoor de kaart een uniforme verschijning heeft over Europa. Kijk eens naar de autoweg N3? Twee rode strepen met een witte middenstreep. Vergelijk de autosnelweg: twee rode strepen met een gele middenstreep. Vergelijk ook de N214 (geen autoweg) iets noordelijker: 1 gele streep. Dit is wel een afspiegeling van het uiterlijk van de weg. N3 is een 2+2 met middenberm en ziet eruit als een autosnelweg, terwijl de N214 een 'klassieke' 1+1 provinciale weg is. Ik moet wel zeggen dat dit 1 van de weinige uitzondering qua autoweg is die ik gevonden heb. Bijvoorbeeld de N62, die door de Westerscheldetunnel weg loopt, een autoweg, is oranje. * MS Live Maps rendert trunk roads eveneens niet in een afzonderlijke kleur. Dezelfde N3: oranje. Dezelfde N214: geel, en tevens een stuk dikker getekend dan de N3! Dezelfde N62: oranje. * Yahoo maps doet het eveneens zo. Zelfde als MS: N3 wordt anders gerendert dan N214. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] fietsen door de Ijtunnel
2008/9/8 Lambert Carsten [EMAIL PROTECTED]: Naar aanleiding van een bericht op de engelse talk lijst van Lambertus over een nieuwe versie van de route planner (dat er zoietsl bestond buiten Duitsland was mij zelfs ontgaan!): http://tile.openstreetmap.nl/~lambertus/routing-world testte ik het even uit en ontdekte dat ik door de ijtunnel in Amsterdam kon fietsen! Niets ten nadele van de route planner. Wat ontzettend gaaf dat dit er eindelijk is. De rest van de thread is ook interressant, maar ik heb een andere vraag: Is er geen fiets/loop tunnel naast de Ijtunnel? Ik woon niet in Amsterdam, maar een aantal van de grote tunnels in Rotterdam hebben slurven ernaast waardoor je kan fietsen. Mvg, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [Talk-de] Openrouteservice fürs Fahrrad
Am Sonntag, 7. September 2008 01:16 schrieb Sven Geggus: Dirk Stöcker [EMAIL PROTECTED] wrote: Btw, es ist immer noch ein Bug drin, den ich schonmal bemängelt habe (siehe angehängtes GPX): ORS schickt mich auf mehreren Abschnitten entgegen der Einbahnstraßenrichtung Pah! Ich möchte ein Feature haben um sowas explizit _einzuschalten_! Hier in der Gegend ist das bei jeder zweiten Einbahnstraße sowieso legal. Dann kannst du das ja in OSM einpflegen. Und das wirst da ntürlich eher machen, wenn er dich sonst nicht durch die Einbahnstraße schickt. Gruß Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Anfängerfrage: Wie einen Track in J OSM/Potlatch hinzufügen?
Hallo, ich antworte mir einfach selbst und hoffe, dass das in Ordnung für euch ist und beantworte hoffentlich alle Fragen, die noch aufgekommen sind. Aufjeden Fall erstmal vielen Dank für die vielen Antworten. Ich glaube, dass das Hauptproblem war, dass ich keine Ahnung gehabt habe, wie ich von den GPX-Daten zu Straßen kommen soll und mir selbst ausgedacht habe, wie das wohl funktionieren müsste. Diese Annahme war falsch und ich habe mich immer weiter in diese Annahme gesteigert. Selbst das Lesen von Tutorials war nicht besonders hilfreich, einfach weil ich diese auch durch meine rosa Brille gelesen habe und dort natürlich nicht meine falschen Annahmen bestätigt wurden. Tatsächlich geht das Nachzeichnen der Tracks deutlich schneller als ich erwartet habe und ich werde es auch in Zukunft so handhaben. Natürlich wird der Track unverändert hochgeladen werden. Mit dem bisher eingefügten Track: Mir ist klar, dass da noch ein paar Fehler vorhanden sind, z.B. gibt es Straßen, die einfach irgendwann auf der Straße plötzlich den Namen ändern. Ohne einen zusätzlichen Anhaltspunkt bin ich da relativ hilflos, zumal halt noch vieles an Straßen fehlt. Ein ganz grobes Netz ist vorhanden, quasi jede Straße innerhalb der Dörfer fehlt, von den Feldwegen mal abgesehen (von denen es wirklich sehr sehr sehr viele gibt). Ich werde zusehen möglichst nur noch dort zu fahren, wo es bisher keine Daten gibt, einfach um die Region besser mappen zu können. Ein arbeitsloser Bekannter von mir hat sich ebenfalls bereit erklärt mit dem GPS durch die Gegend zu laufen um weitere Punkte zu erfassen. Mein Ziel ist es erstmal das Straßennetz inklusive aller Namen zu erfassen. Dann kann man POIs hinzufügen und das Netz sollte eine gute Ausgangsposition für andere darstellen. Tankstellen etz. werde ich evtl. gleich von vorne herein mit hinzufügen aber das werde ich mal sehen. Hier noch ein kleines Problem: Bei uns in der Region haben einige Straßen keinen eigenen Namen sondern nutzen den von der Paralellstraße oder von einer Angrenzenden. JOSM bietet die Möglichkeit mit P und C Straßen zu trennen und zu verbinden. Leider kann ich einige Straßen nicht miteinander verbinden und angegebene Fehler ist: Kann Wege nicht verbinden (Sie können nicht in eine eindeutige Reihenfolge gebracht werden). Besonders gut sieht man es in der Mitte des Ortes. Dort gibt es bisher drei Straßen (residential) mit dem Namen Birkenweg, obwohl dies eigentlich alles eine Straße ist. Ich würde diese Straßen gerne alle zu einer Straße hinzufügen. Hier der Permalink: http://www.openstreetmap.org/?lat=49.6981lon=7.15562zoom=15layers=B00FTF Vielleicht hat jemand von euch einen Tipp für mich, wie ich die Straßen miteinander verbinden kann. Was ich auch nicht verstehe ist, warum der Weg eine Richtungsangabe hat. Bei einer Einbahnstraße kann ich es ja noch verstehen aber nicht bei beidseitig befahrbaren Straßen. Wozu ist diese Richtungsangabe dar? Wie mache ich es mit Straßen, die zwei verschiedene Geschwindigkeitsbegrenzungen haben. Speziell ist es die Hauptstraße, die an die B 269 grenzt, die mir Sorgen macht. Dort darf man teilweise 100 fahren, teilweise nur 70 und innerorts nur 50 (an einer Stelle sogar nur 30). Wenn ich die Geschwindigkeitsbegrenzung setze, dann kann ich sie innerorts nicht anders wählen als außerorts, da immer die ganze Straße angewählt wird. Liebe Grüße Jan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Anfängerfrage: Wie einen Track in J OSM/Potlatch hinzufügen?
Hallo Jan, da musst Du die Straße dann eben doch in Teilstücke trennen und entsprechend unterschiedliche Attributierung bzgl. Geschwindigkeitsbegrenzung angeben. Im gewachsenen Straßennetz steht der Straßenname eben nicht (wie man das oft im Kopf hat) für ein homogenes Straßenstück. In Kirchzarten (my mappingvillage) geht die Hauptstraße von normaler residental in Spielstraße, dann in Fußgängerzone und am Ende in eine Durchgangsstraße über. Diese Straße hohogen taggen zu wollen würde stark an der Realität vorbeigehen. Deswegen besteht die Hauptstraße aus den attributiv homogenen Teilstücken die den gleichen Straßennamen tragen, aber adjazent, also benachbart sind und somit vom Begriff her eine Straße bilden (die mit dem Auto so gar nicht am Stück befahrbar ist). Auch für Kartendarstellungen ist es sinnvoll hier jedem Teilstück den Namen zu geben, damit man den Verlauf der Straße dem Namen nach verfolgen kann (z.B. wenn man konkret eine Adresse sucht und nicht genau weiß wo die Hausnummer 99 ist). Aus dem Kartenbild und auch in der Realität würde man hier nie EINE Straße vermuten - ist ja auch nicht mehr wirklich eine. Der Name ist natürlich historisch gewachsen und hat sich entsprechend erhalten. Attribute von Verkehrswegen lassen sich in der Realität eben leichter ändern als Straßenbezeichnungen. Marco P.S. falls Du im Wiki Deinen Standort noch nicht eingetragen hast, solltest Du das tun. So finden Dich Mapper die möglicherweise in Deiner Gegend unterwegs sind - evtl. ergibt sich daraus ja eine richtige Mappinggruppe, ... http://wiki.openstreetmap.org/index.php/Category:Users_in_Rheinland-Pfalz Wie mache ich es mit Straßen, die zwei verschiedene Geschwindigkeitsbegrenzungen haben. Speziell ist es die Hauptstraße, die an die B 269 grenzt, die mir Sorgen macht. Dort darf man teilweise 100 fahren, teilweise nur 70 und innerorts nur 50 (an einer Stelle sogar nur 30). Wenn ich die Geschwindigkeitsbegrenzung setze, dann kann ich sie innerorts nicht anders wählen als außerorts, da immer die ganze Straße angewählt wird. begin:vcard fn:Marco Lechner n:Lechner;Marco org;quoted-printable;quoted-printable:Universit=C3=A4t Freiburg;Institut f=C3=BCr Physische Geographie adr:;;Werthmannstr. 4;Freiburg;;79085;Deutschland email;internet:[EMAIL PROTECTED] tel;work:+49(0)761/203-3548 tel;fax:+49(0)761/203-3596 url:http://www.geographie.uni-freiburg.de version:2.1 end:vcard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Anfängerfrage: Wie einen Track in J OSM/Potlatch hinzufügen?
On Mon, 8 Sep 2008, Jan wrote: Hier noch ein kleines Problem: Bei uns in der Region haben einige Straßen keinen eigenen Namen sondern nutzen den von der Paralellstraße oder von einer Angrenzenden. JOSM bietet die Möglichkeit mit P und C Straßen zu trennen und zu verbinden. Leider kann ich einige Straßen nicht miteinander verbinden und angegebene Fehler ist: Kann Wege nicht verbinden (Sie können nicht in eine eindeutige Reihenfolge gebracht werden). Besonders gut sieht man es in der Mitte des Ortes. Dort gibt es bisher drei Straßen (residential) mit dem Namen Birkenweg, obwohl dies eigentlich alles eine Straße ist. Ich würde diese Straßen gerne alle zu einer Straße hinzufügen. Ein Weg ist immer eine Linie. Versuche nicht mit irgendwelchen Konstrukten nicht linienartige Straßen zu verbinden. Es ist ok, wenn viele Teilstücke den gleichen Namen tragen (geht bei Brücken z.B. auch nicht anders). Falls das Verbinden von Teilstücken nicht klappt, welche direkt hintereinander liegen, dann musst Du nachschauen, ob am Verbindungspunkt etwas nicht stimmt (z.B. zwei nicht verbundene Punkte statt einem). Was ich auch nicht verstehe ist, warum der Weg eine Richtungsangabe hat. Bei einer Einbahnstraße kann ich es ja noch verstehen aber nicht bei beidseitig befahrbaren Straßen. Wozu ist diese Richtungsangabe dar? Die Richtungsangabe entsteht aus der Reihenfolge der Knoten. In JOSM gibt es eine Option die Richtungspfeile nur bei interessanten Objekten (z.B. Einbahnstraßen) anzuzeigen. Wie mache ich es mit Straßen, die zwei verschiedene Geschwindigkeitsbegrenzungen haben. Speziell ist es die Hauptstraße, die an die B 269 grenzt, die mir Sorgen macht. Dort darf man teilweise 100 fahren, teilweise nur 70 und innerorts nur 50 (an einer Stelle sogar nur 30). Wenn ich die Geschwindigkeitsbegrenzung setze, dann kann ich sie innerorts nicht anders wählen als außerorts, da immer die ganze Straße angewählt wird. Immer wenn sich etwas ändert, teilst Du die Straße in zwei Abschnitte und gibst jedem Abschnitt die entsprechenden Tags. --- --- -70---50-30---100- ergibt 5 Teilstücke. Auf der Karte kann es sein, dass das nicht unbedingt perfekt aussieht, weil die Renderer momentan noch zu dumm sind die Namens- und Referenz-Angaben wieder zusammenzufügen. Lass Dich davon nicht stören. Irgendwann lernen die das auch noch. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Anfängerfrage: Wie einen Track in J OSM/Potlatch hinzufügen?
Hallo, Jan [EMAIL PROTECTED] writes: überhaupt. Dann ggf. noch andere Punkte, z.B. das Einmessen in den ersten 20 Minuten. Ich muss keine 1400 Punkte hochladen, die alle mehr oder weniger den gleichen Punkt darstellen oder soll ich die Punkte vom Einmessen ebenfalls hochladen? mache es dir doch einfacher und lösche den Trackspeicher nachdem du dein Gerät eingemessen hast. Wenn du die Daten von vorher behalten willst kannst du alternativ auch einfach die Trackaufzeichnung während des Einmessens abschalten. Viele Grüße Sebastian Waschik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Stark vereinfachte Karten aus OSM-Daten
Hallo. Ich hatte grade (mal wieder) den Gedanken, dass ich meine Anfahrt-Skizzen [1] eigentlich schon gerne mit OSM-Daten machen will. Die gleichen Skizzen verwende ich auch in einem gedruckten Flyer, es muss also stark vereinfacht dargestellt sein, sonst erkennt man gar nichts mehr. Nach einigen verzweifelten Versuchen mit einem SVG-Export und Barbeitung des selbigen in inkscape habe ich grade beschlossen, dass dieser Weg nicht gangbar ist. Daher die Frage: Lassen sich derart vereinfachte Karten überhaupt sinnvoll automatisiert aus OSM-Kartenmaterial erstellen? Oder ist man da immer schneller wenn man es selbst z.B. anhand einer dahinter gelegten OSM-Karte nachzeichnet? [1]: http://www.suessmost.de/kontakt/anfahrt.html Gruß, Bernd -- Windows Error 005: Multitasking attempted. System confused. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stark vereinfachte Karten aus OSM-Daten
Hallo. Am Montag, 8. September 2008 schrieb Dirk Stöcker: Nach einigen verzweifelten Versuchen mit einem SVG-Export und Barbeitung des selbigen in inkscape habe ich grade beschlossen, dass dieser Weg nicht gangbar ist. Warum? z.B. weil jedes in den Daten getrennte Stückchen Straße aus zwei hintereinander liegenden Linien besteht, die man nur schwer gezielt selektieren kann. Wenn die Straßen, die ich haben will, auch noch aus vielen kleinen Stückchen bestehen (Brücken, Geschwindigkeitsbegrenzungen, ...), ist das eine Heiden-Arbeit alleine diese Straßen-Stückchen zu separieren. Dazu kommt, dass (Mapnik-)Brücken sich nicht direkt in den Stil von normalen Straßen umwandeln lassen, da diese mit einer anderen Breite gerendert werden. Ich hab's mir recht einfach vorgestellt, aber irgendwie ist das nix... Zugegeben ist die Ebenen-Verwaltung von Inkscape nicht der Weisheit letzter Schluss und mit einem besseren Programm könnte es evtl leichter gehen. Aber dennoch muss das einfacher gehen. :) Gruß, Bernd -- Press ESC to detonate or any other key to explode signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Openrouteservice fürs Fahrrad
Am 08.09.2008 um 11:22 schrieb Martin Koppenhoefer: Am 8. September 2008 08:05 schrieb Sven Anders [EMAIL PROTECTED] hamburg.de: Am Sonntag, 7. September 2008 01:16 schrieb Sven Geggus: Dirk Stöcker [EMAIL PROTECTED] wrote: Btw, es ist immer noch ein Bug drin, den ich schonmal bemängelt habe (siehe angehängtes GPX): ORS schickt mich auf mehreren Abschnitten entgegen der Einbahnstraßenrichtung Pah! Ich möchte ein Feature haben um sowas explizit _einzuschalten_! Hier in der Gegend ist das bei jeder zweiten Einbahnstraße sowieso legal. Dann kannst du das ja in OSM einpflegen. Und das wirst da ntürlich eher machen, wenn er dich sonst nicht durch die Einbahnstraße schickt. Gruß Sven wie sollte man das denn taggen? bicycle=opposite? access:bicycle=both? oneway:bicycle=no? Hallo, ich bin zwar noch nicht lange dabei, aber da ich gestern über die Wikieinträge zu cycleway gestolpert bin. Ist nicht cycleway oposite_lane Ein Radfahrstreifen (cycle lane) entgegen der Fahrrichtung einer Einbahnstraße. http://wiki.openstreetmap.org/index.php/De:Map_Features#Fahrradwege genau für diesen Fall gedacht? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stark vereinfachte Karten aus OSM-Daten
Moin Bern On Monday 08 September 2008 10:36:44 Bernd Wurst wrote: Die gleichen Skizzen verwende ich auch in einem gedruckten Flyer, es muss also stark vereinfacht dargestellt sein, sonst erkennt man gar nichts mehr. Solange sich stark vereinfacht nur darauf bezieht bestimmte Straßentypen und Punkte für Ortschaften Anzeigen zu lassen, sollte das machbar sein. Solltest Du mit stark vereinfacht auch etwas an den Proportionen etc. ändern wollen, dann wird das wohl schwerer. Kosmos [1] wäre hier eine recht einfache Möglichkeit, das aussehen der Karte so anzupassen, wie Du es gerne hättest. Erfordert allerdings erstmal das erstellen der Renderregeln, die in deinem Falle allerdings recht kurz ausfallen dürften. Gruß Jörg [1] http://wiki.openstreetmap.org/index.php/Kosmos ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Anfängerfrage: Wie einen Track in JO SM/Potlatch hinzufügen?
Hi, Am 8. September 2008 09:44 schrieb Dirk Stöcker [EMAIL PROTECTED]: On Mon, 8 Sep 2008, Jan wrote: Wie mache ich es mit Straßen, die zwei verschiedene Geschwindigkeitsbegrenzungen haben. Speziell ist es die Hauptstraße, die an die B 269 grenzt, die mir Sorgen macht. Dort darf man teilweise 100 fahren, teilweise nur 70 und innerorts nur 50 (an einer Stelle sogar nur 30). Wenn ich die Geschwindigkeitsbegrenzung setze, dann kann ich sie innerorts nicht anders wählen als außerorts, da immer die ganze Straße angewählt wird. Immer wenn sich etwas ändert, teilst Du die Straße in zwei Abschnitte und gibst jedem Abschnitt die entsprechenden Tags. --- --- -70---50-30---100- ergibt 5 Teilstücke. Wobei man dazu sagen muss, dass es (meines Wissens) momentan noch keine Möglichkeit gibt, nicht-symmetrische Geschwindigkeitsbegrenzungen abzubilden. Wenn in eine Richtung also eine andere Geschwindigkeitsbegrenzung, als in die andere gilt (oder die andere Fahrtrichtung keine Begrenzung hat), dann hast du ein Problem. Tschüss, Tim. -- http://wikipedistik.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Hünengrab taggen ?
Moin ! bei uns in der Gegend gibt es viele Hünengräber - Archologische Ausgabungsstätten sind das ja nicht mehr unbedingt !??!?! Wie tackt Ihr die ?? Gruß Jan :-) --- OpenStreetMap (OSM) - das FREIE Kartenprojekt http://www.openstreetmap.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hierarchische Relation
Hi, das war offensichtlich ein Irrtum, wie Ale_Zena geschrieben hat, es waere also gut, wenn jemand, der weiss wie es geht, das bitte so wiederherstellen koennte, wie es vor seinem Edit war. Hab ich probiert, ging aber nicht, weil User PieSchie mittlerweile ein grosses Stueck der Grenze Italien-Oesterreich enternt hat (den Way 8072284), daher musste ich den aus der Relation rauslassen, um sie wiederherstellen zu koennen. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stark vereinfachte Karten aus OSM-Daten
Hallo. Am Montag, 8. September 2008 schrieb Dirk Stöcker: Hmm. Mach es doch zweistufig: a) In JOSM Karte vereinfachen. b) SVG erzeugen c) In Inkscape noch etwas verhübschen. Alternativ wäre für a) natürlich ein Skript toll, aber das ist wohl etwas aufwändiger. Klar. Ich wollte eigentlich ein Mapnik-Bild als Ausgangsbasis benutzen, aber das gebe ich auf. Mapnik mit allem drum und dran selbst du betreiben, steht zwar auch hier ganz unten auf der todo-liste, aber erstmal nicht. :) Ich kille jetzt mal aus einem Osmarender-Stylesheet alles raus was ich nicht haben will und schau mir an was ich damit für Ergebnisse bekomme... Gruß, Bernd -- Toleranz ist nur die Angst davor, daß der andere vielleicht doch recht hat. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Openrouteservice fürs Fahrrad
Am 8. September 2008 08:05 schrieb Sven Anders [EMAIL PROTECTED]: Am Sonntag, 7. September 2008 01:16 schrieb Sven Geggus: Dirk Stöcker [EMAIL PROTECTED] wrote: Btw, es ist immer noch ein Bug drin, den ich schonmal bemängelt habe (siehe angehängtes GPX): ORS schickt mich auf mehreren Abschnitten entgegen der Einbahnstraßenrichtung Pah! Ich möchte ein Feature haben um sowas explizit _einzuschalten_! Hier in der Gegend ist das bei jeder zweiten Einbahnstraße sowieso legal. Dann kannst du das ja in OSM einpflegen. Und das wirst da ntürlich eher machen, wenn er dich sonst nicht durch die Einbahnstraße schickt. Gruß Sven wie sollte man das denn taggen? bicycle=opposite? access:bicycle=both? oneway:bicycle=no? Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Openrouteservice fürs Fahrrad
Wolfgang van Oorschot: Am 08.09.2008 um 11:22 schrieb Martin Koppenhoefer: Am 8. September 2008 08:05 schrieb Sven Anders [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Am Sonntag, 7. September 2008 01:16 schrieb Sven Geggus: Dirk Stöcker [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Btw, es ist immer noch ein Bug drin, den ich schonmal bemängelt habe (siehe angehängtes GPX): ORS schickt mich auf mehreren Abschnitten entgegen der Einbahnstraßenrichtung Pah! Ich möchte ein Feature haben um sowas explizit _einzuschalten_! Hier in der Gegend ist das bei jeder zweiten Einbahnstraße sowieso legal. Dann kannst du das ja in OSM einpflegen. Und das wirst da ntürlich eher machen, wenn er dich sonst nicht durch die Einbahnstraße schickt. Gruß Sven wie sollte man das denn taggen? bicycle=opposite? access:bicycle=both? oneway:bicycle=no? Hallo, ich bin zwar noch nicht lange dabei, aber da ich gestern über die Wikieinträge zu cycleway gestolpert bin. Ist nicht cycleway oposite_lane Ein Radfahrstreifen (cycle lane) entgegen der Fahrrichtung einer Einbahnstraße. http://wiki.openstreetmap.org/index.php/De:Map_Features#Fahrradwege genau für diesen Fall gedacht? Nur wenn es ein eigener Fahrstreifen entgegen der Einbahnstraßenrichtung ist. Ansonsten (Fahrradfahrer dürfen Einbahnstraße in Gegenrichtung befahren) müsste der Weg so aussehen: highway=residential/tertiary/was-auch-immer oneway=yes cycleway=opposite ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stark vereinfachte Karten aus OSM-Daten
OSM-Export-Karten generalisieren? Ich meine (aus Selbstversuchen), da ist man in den meisten Fällen schneller, das per Hand (zB in Inkscape) durch Neuzeichnen selbst zu machen. Ich habe das (mit OSM-Daten) auch schonmal in ArcGIS automatisiert probiert, da gibt es ja nun schon sehr ausgefeilte Generalisierungsfunktionen; aber diese dahin zu prügeln, dass sie genau das Richtige machen... viel zu mühsam (für kleinere Karten). Zumindest für Straßendaten, wo man sich mit sowas wie Auffahrten oder parallelen Spuren rumschlagen muss. Einfacher siehts da schon mit Flächen, wzB. Seen, Wälder oder auch Gebäuden aus; hier habe ich mit ArcGIS (mit GRASS sollte es auch gehen) schon ziemlich gute Ergebnisse erzielen können, die bei Gebäuden zB auch die rechten Winkel behalten. Alex Bernd Wurst schrieb am 08.09.2008 10:36: Nach einigen verzweifelten Versuchen mit einem SVG-Export und Barbeitung des selbigen in inkscape habe ich grade beschlossen, dass dieser Weg nicht gangbar ist. Daher die Frage: Lassen sich derart vereinfachte Karten überhaupt sinnvoll automatisiert aus OSM-Kartenmaterial erstellen? Oder ist man da immer schneller wenn man es selbst z.B. anhand einer dahinter gelegten OSM-Karte nachzeichnet? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: Validator - Nicht verbundene Wege
Dirk Stöcker schrieb: ich habe gerade einen neuen Validator-Test fertiggestellt, welche auf unverbundene Wege prüft. Geprüft werden freiliegende Endpunkte von Wegen. ich bin begeistert! und erschreckt, wie viele fehler doch noch in meiner - von solchen fehlern frei geglaubte - heimatregion da doch noch zum vorschein kam. Es gibt noch eine zweite Option: validator.UnconnectedWays.way_way_distance=0.0 Wird diese auf Werte größer 0 gesetzt, so werden auch Knoten in der Mitte oder verbundene Endpunkte geprüft. Das dauert allerdings sehr lange stimmt, vielleicht gibts da noch optimierungsmöglichkeiten. und hat bei mir nur falsche Warnung gebracht. bei mir kamen da noch einige fehler zum vorschein. grüße frank ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stark vereinfachte Karten aus OSM-Daten
Hallo. Am Montag, 8. September 2008 schrieb Etric Celine: Solange sich stark vereinfacht nur darauf bezieht bestimmte Straßentypen und Punkte für Ortschaften Anzeigen zu lassen, sollte das machbar sein. Ich hatte ja gehofft, jemand hat schon ein stark geschrumpftes Osmarender-Stylesheet in petto und sagt mir wo ich das finde. ;-)) Solltest Du mit stark vereinfacht auch etwas an den Proportionen etc. ändern wollen, dann wird das wohl schwerer. Wenn man mal ein SVG mit nur interessanten Dingen hat, kann man sowas ja dann noch nachträglich machen. Ich denke schon, dass man das leicht verzerren muss, sonst verschwendet eine solche Karte zu viel Platz. Kosmos [1] wäre hier eine recht einfache Möglichkeit, das aussehen der Karte so anzupassen, wie Du es gerne hättest. Erfordert allerdings erstmal das erstellen der Renderregeln, die in deinem Falle allerdings recht kurz ausfallen dürften. [...] [1] http://wiki.openstreetmap.org/index.php/Kosmos Zitat: | As for the Linux/Mono support, there was some effort on my and other | people's part to make Kosmos v1.x run on Linux. However there were quite a | few problems with this. Also, the new Kosmos 2.0 contains some 3rd party | libraries which are not very friendly to Mono. That is why I decided not to | try to support Kosmos 2.0 for Linux Wird also wohl nix werden... Leider ist Osmarender kein Paradebeispiel für einfache Rulesets, aber ich denke ich muss mir dafür mal einen eigenen, stark vereinfachten Style erstellen. :) Gruß, Bernd -- Schade, daß rote Zahlen auf dem Konto nicht annähernd so beruhigend sind wie auf dem Kalender. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hierarchische Relation
Am 7. September 2008 21:50 schrieb Martin Koppenhoefer [EMAIL PROTECTED]: 2008/9/7 Raphael Studer [EMAIL PROTECTED] http://osm.schunterscouts.de/relation-browser.php War da nicht mal Italien auch noch drin? Wär schön wenn man aus der Relation http://www.openstreetmap.org/api/0.5/relation/16240/history wieder den letzten Stand laden könnte. Ale_Zena_IT hat da wohl etwas gar viel gelöscht. Grüsse Raphael ich hab das mal in Italien auf der ML gepostet, Ale Zena IT kenne ich dort aus der ML, deshalb glaube ich nicht, dass er absichtlich dort was gelöscht hat. Gruss Martin das war offensichtlich ein Irrtum, wie Ale_Zena geschrieben hat, es waere also gut, wenn jemand, der weiss wie es geht, das bitte so wiederherstellen koennte, wie es vor seinem Edit war. vielen Dank, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=cycleway cycleway=track
GeoJ wrote: ich bin gerade in meiner Gegend über die Kombination highway=cycleway cycleway=track gestolpert. [...] So ganz passt das aber IMHO nicht in das Schema, wie ich es bisher kenne - stimmt ihr mir da zu? Es passt nicht; da bin ich derselben Meinung. Nun hat aber Potlatch gerade auf Neulinge einen starken Einfluss - das Preset für Radwege gibt dort genau diese Kombination vor. Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Openrouteservice fürs Fahrrad
Wolfgang van Oorschot wrote: Am 08.09.2008 um 11:22 schrieb Martin Koppenhoefer: [zu Einbahnstraßen mit Erlaubnis für Fahrräder in Gegenrichtung] wie sollte man das denn taggen? bicycle=opposite? access:bicycle=both? oneway:bicycle=no? Ist nicht cycleway oposite_lane Ein Radfahrstreifen (cycle lane) entgegen der Fahrrichtung einer Einbahnstraße. http://wiki.openstreetmap.org/index.php/De:Map_Features#Fahrradwege genau für diesen Fall gedacht? cyclceway=opposite_lane ist für eine auf dem Boden sichtbar markierte Fahrspur für den in Gegenrichtung fahrenden Radfahrer. Fehlt dieser (und ist also nur durch Zusatzschilder klargestellt, dass hier Radfahrer auch entgegen der Richtung der Einbahnstraße fahren dürfen), dann ist cycleway=opposite die richtige Kennzeichnung. Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] eigene Luftbilder?!
Liebe OSM-Spezialisten, wer kann denn mal im Wiki eine deutsche Anleitung schreiben, wie man Luftbilder so erstellt, dass sie für die Kartenarbeit verwendbar sind? Und wie man diese dann einsetzt (in Editor einbinden, georeferenzieren)? Müsste als Anleitung für Piloten (und Copiloten) taugen... Herzlichen Dank, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] eigene Luftbilder?!
Markus schrieb: Liebe OSM-Spezialisten, wer kann denn mal im Wiki eine deutsche Anleitung schreiben, wie man Luftbilder so erstellt, dass sie für die Kartenarbeit verwendbar sind? Und wie man diese dann einsetzt (in Editor einbinden, georeferenzieren)? Müsste als Anleitung für Piloten (und Copiloten) taugen... Auch welche Figuren zu fliegen sind um die besten Ergebnisse zu erzielen. Gruß, Stephan. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hünengrab taggen ?
Moin, Jan Tappenbeck schrieb: bei uns in der Gegend gibt es viele Hünengräber - Archologische Ausgabungsstätten sind das ja nicht mehr unbedingt !??!?! Wie tackt Ihr die ?? Ich tacke nicht, wenn schon Denglisch, dann tagge ich. Ansonsten scheint mir da historic=archaeological_site passend genug, auch wenn es vielleicht nicht ganz der Beschreibung bei den Mapfeatures entspricht. Die offizielle Ausschilderung vom Denkmalschutz ist vom Schil her ja auch die selbe, egal ob das freiliegende Grabreste sind oder nicht. Vielleicht muss man das Huenengrab einfach als potentielle Ausgrabungsstaette sehen :-) Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stark vereinfachte Karten aus OSM-Daten
Alexrk schrieb: Einfacher siehts da schon mit Flächen, wzB. Seen, Wälder oder auch Gebäuden aus; hier habe ich mit ArcGIS (mit GRASS sollte es auch gehen) schon ziemlich gute Ergebnisse erzielen können, die bei Gebäuden zB auch die rechten Winkel behalten. Yopp, GRASS kann es auch (ich darf mein ArcGIS leider nicht für OSM nutzen). ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbank der Kulturgüter in der Regio n Trier
Hallo Roman, Roman Grabolle schrieb: oder doch zumindest Teile dieser in die OSM einzupflegen. Da ist alles dabei, von prähistorische Befestigungen über mittelalterliche Burgen und Klöster bis hin zu heutigen Museen und Kulturzentren. ich würde mich gerne anbieten (NRW-Ticket reicht bis Trier). In welcher Basis liegen die Daten denn vor? Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] eigene Luftbilder?!
Friedhelm Schmidt schrieb: Beispiel FlycamOne-2: http://labs.metacarta.com/rectifier/rectify/619 Sehr cool. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] eigene Luftbilder?!
Hallo Markus, Markus schrieb: wer kann denn mal im Wiki eine deutsche Anleitung schreiben, wie man Luftbilder so erstellt, dass sie für die Kartenarbeit verwendbar sind? Und wie man diese dann einsetzt (in Editor einbinden, georeferenzieren)? http://wiki.openstreetmap.org/index.php/Georeferenzierung Müsste als Anleitung für Piloten (und Copiloten) taugen... Ich finde, diese müssten sich damit gar nicht abgeben, denn so ein Überflug wäre schon genug Aufwand. Die Auswertung würden sichere andere Leute, wie ich z.B., gerne übernehmen. Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Trigonometrische Punkte
Dirk Stöcker schrieb: GPS ist in dieser Form nicht kalibrierbar. Die GPS-Genauigkeit ist von vielen Faktoren abhänging, welche sich alle mit der Zeit ändern. Du kannst Dich also nicht auf einen bekannten Punkt stellen, den aktuellen Offset bestimmen und annehmen, dass dieser für die ganze Messung gilt. Das stimmt so nicht ganz: Post-Processed D-GPS hat eine Genauigkeit von wenigen Dezimetern. Wichtig ist allerdings, dass die Uhr im GPS-Empfänger _höchst_ genau geht, dass Du jede einzelne Position des Satelliten sowie die Sichtweite kennst (und natürlich die Faktoren, wie Wetter, die das Signal beeinflussen - Basisstation muss in der Nähe der Messung stehen) und dass Du den Algorithmus kennst, wie das GPS-Gerät die Daten ausrechnet oder halt die Korrekturdaten direkt einfließen (WAAS/EGNOS ähnlich). ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] GPS-Geräteempfehlung
Liebe Erfahrene, unser Fremdenverkehrs- und Verschönerungsverein hat mich gefragt, was für ein GPS sie denn kaufen sollen - und ich habe keine Ahnung... Sie wollen: - Wanderwege loggen - Fahrradwege loggen - Sitzbänke, Feuerstellen, Schutzhütten, etc - Wirtshäuser, Schlösser, Sehenswürdigkeiten also alles was über die Strassen hinausgeht. Und natürlich das Ganze dann als OSM-Karte im Gerät anzeigen: - die OSM-Grundkarte + alle die selbst ermittelten Daten, die die Renderer (noch) nicht anzeigen... Welches Gerät soll ich ihnen empfehlen? Nach welchen Kriterien? Zu welchem Preis? Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Openrouteservice fürs Fahrrad
Am 08.09.2008 um 15:49 schrieb Hatto von Hatzfeld: Wolfgang van Oorschot wrote: Am 08.09.2008 um 11:22 schrieb Martin Koppenhoefer: [zu Einbahnstraßen mit Erlaubnis für Fahrräder in Gegenrichtung] wie sollte man das denn taggen? bicycle=opposite? access:bicycle=both? oneway:bicycle=no? Ist nicht cycleway oposite_lane Ein Radfahrstreifen (cycle lane) entgegen der Fahrrichtung einer Einbahnstraße. http://wiki.openstreetmap.org/index.php/De:Map_Features#Fahrradwege genau für diesen Fall gedacht? cyclceway=opposite_lane ist für eine auf dem Boden sichtbar markierte Fahrspur für den in Gegenrichtung fahrenden Radfahrer. Fehlt dieser (und ist also nur durch Zusatzschilder klargestellt, dass hier Radfahrer auch entgegen der Richtung der Einbahnstraße fahren dürfen), dann ist cycleway=opposite die richtige Kennzeichnung. Ok soweit verstanden. Ich hoffe ihr seht das nicht als Thread kapern, aber da hier ja die Radwegprofis versammelt zu sein scheinen erlaube ich mir noch eine Frage aus meiner Praxis. Innerörtliche zweispurige Straße - auf der einen Seite Radweg auf der Fahrbahn durch Markierung gekennzeichnet. Auf der Gegenseite baulich abgesetzter Radweg. Ich finde keine Tags die dieses Szenario erfassen würden. Gruss Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Treffen mit dem Vermessungs- Katasteramt Dortmund
Hallo Leute, Marcus Schäfer und ich hatten heute von 14 bis 16 Uhr einen Termin beim Vermessungs- und Katasteramt Dortmund. Das Gespräch wurde sehr offen und freundlich geführt und man verfolgt das OSM-Geschehen aufmerksam. Generell landen alle Geodatenanfragen auf dem Tisch der Dortmunder auch die Anfragen an den RVR. Hauptsächlich wurde dargestellt, welche Bedürfnisse wir eigentlich an die Stadt Dortmund stellen (z.B. Basiskarten zur Korrektur unserer GPS-Daten). Nach einer Grundsatz- und Konkurrenz-Diskussion haben sich folgende Punkte herauskristallisiert: 1. Generell wird intern darüber diskutiert, WMS-Dienste bereitzustellen, aus denen wir Informationen ableiten können (Tempo 30 Zonen, Radwege). 2. Es wird überlegt, uns Straßenkreuzungspunkte zu überlassen, an denen wir unsere GPS-Tracks korrigieren bzw. orientieren können. 3. Eine Übernahme von Stadt-/Stadtteil-Grenzen ist problematisch, da eine Grenzverschiebung in unseren Daten kommunal-politische Konflikte auslösen könnte. 4. Eine von uns geäußerte Wunschliste (z.B. Straßenverzeichnis etc.) wird auch intern erörtert. Es wurde vorgeschlagen, auf das Telefonbuch der Telekom zurückzugreifen, allerdings ist dies seit einiger Zeit nicht mehr ohne Genehmigung möglich und wird rechtlich streng verfolgt. 5. Ein Joint-Venture wurde angedacht: Die Stadt gibt uns Informationen und wir geben dafür Informationen zurück. Als Beispiel wurden Informationen über Barrierefreiheit genannt. Voraussetzung wäre allerdings ein Verein, der dann auch haftbar gemacht werden kann (na das wird jetzt wieder eine Diskussion entfachen...). Wie gerade bekannt wurde, ist am 17.09.2008 aein Treffen mit dem RVR geplant, bei dem 15 kommunale Vertreter aus dem Ruhrgebiet eingeladen werden. Die Entscheidung der Stadt Dortmund wird also sicherlich von der des RVRs abhängen. Viele Grüße Tobias ps: In der Zukunft wird die Stadt Dortmund ein neues Informationssystem für die Bürger einführen, welches auf OpenLayers basiert. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Trigonometrische Punkte
On Mon, 8 Sep 2008, Tobias Wendorff wrote: Dirk Stöcker schrieb: GPS ist in dieser Form nicht kalibrierbar. Die GPS-Genauigkeit ist von vielen Faktoren abhänging, welche sich alle mit der Zeit ändern. Du kannst Dich also nicht auf einen bekannten Punkt stellen, den aktuellen Offset bestimmen und annehmen, dass dieser für die ganze Messung gilt. Das stimmt so nicht ganz: Post-Processed D-GPS hat eine Genauigkeit von wenigen Dezimetern. Wichtig ist allerdings, dass die Uhr im GPS-Empfänger _höchst_ genau geht, dass Du jede einzelne Position des Satelliten sowie die Sichtweite kennst (und natürlich die Faktoren, wie Wetter, die das Signal beeinflussen - Basisstation muss in der Nähe der Messung stehen) und dass Du den Algorithmus kennst, wie das GPS-Gerät die Daten ausrechnet oder halt die Korrekturdaten direkt einfließen (WAAS/EGNOS ähnlich). Die Uhr im GPS Empfänger muss sowieso _höchst_ genau gehen, sonst funktioniert das normale GPS schon nicht. Das ist auch der Grund warum man mindestens 4 Satelliten empfangen muss um die 3D Position zu bestimmen, es gibt nämlich 4 Unbekannte (3 Raumkoordinaten und die genaue Zeit im Empfänger). Post-Processed D-GPS setzt voraus dass das Gerät die Rohdaten (pseudo-range) aufzeichnet, und das tun die mir bekannten Handgeräte leider nicht. Gerhard___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] eigene Luftbilder?!
Hallo Tobias, im Wiki eine deutsche Anleitung schreiben Ich finde, diese müssten sich damit gar nicht abgeben aber sie bräuchten halt eine Art Arbeitsanweisung: - Flughöhe/Brennweite/Auflösung - Flugmuster - Technisches (wie man die Kamera aus dem Fenster hält oder so) - ... Etwas das sie verstehen (oder das zumindest ich verstehe und ihnen zumindest erklären kann). Die Auswertung würde ich z.B., gerne übernehmen. super! Schreib doch einfach auf was Du weisst und was Du genau brauchst. Gib hier den Wiki-Link bekannt, und vielleicht hat der eine oder andere noch eigenen Ideen oder Erfahrungen dazu... Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: Validator - Nicht verbundene Wege
On Mon, 8 Sep 2008, Tobias Wendorff wrote: ich habe gerade einen neuen Validator-Test fertiggestellt, welche auf unverbundene Wege prüft. Geprüft werden freiliegende Endpunkte von Wegen. Wo finde ich Informationen über alle Options? Welche Optionen? Das einzige, was Du dazu einstellen kannst stand in meiner ersten Mail. Da nicht?! http://wiki.openstreetmap.org/index.php/JOSM/Plugins/Validator Wenn sie irgendjemand dort einträgt, findest Du sie dort auch. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Trigonometrische Punkte
Dirk Stöcker schrieb: Doch. Differential-Verfahren (ob Post-Processed oder in Echtzeit) haben eine permanente Korrektur, die den sich ändernden Bedingungen angepasst wird. Ich schrieb oben, dass eine Einmalkorrektur nicht möglich ist. Obwohl dies (aus Eigenversuch) doch im gewissen Maße möglich ist. Ich habe zwei exakt gleiche Empfänger (Holux M-1000) ausgeliehen. Einer lag auf dem Dach unseres Uni-Gebäudes (Koordinaten waren genau bekannt) und der andere war mit mir unterwegs. Beide verwenden den gleichen Algorithmus, die gleiche Uhr und hatten die gleichen Störungen durch Wetter mitbekommen. Ich habe dann die Differenz zwischen echter Koordinate und den gemessenen Daten der festen Station gebildet und diese dann anteilig auf die mobilen Daten gerechnet. Die Fehlerrate ist um 70% gesunken. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: Validator - Nicht verbundene Wege
Dirk Stöcker schrieb: Wo finde ich Informationen über alle Options? Welche Optionen? Das einzige, was Du dazu einstellen kannst stand in meiner ersten Mail. Ich dachte, Du hättest noch mehr geschaffen (in früheren Versionen). Da nicht?! http://wiki.openstreetmap.org/index.php/JOSM/Plugins/Validator Wenn sie irgendjemand dort einträgt, findest Du sie dort auch. Also wieder Source lesen? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu FON-FIXME
Tobias Wendorff schrieb: Hallo Leute, wieso stecken an den ganzen W-LAN Dingern von FON FIXMEs ? Damit du drüber stolperst und nochmal drauf aufmerksam gemacht wirst, dass diese WLAN-POIs aus einem bislang nicht durch FON autorisierten DB-Import stammen und deshalb wieder gelöscht gehören. Abgesehen davon kann man sich auch trefflich streiten, ob in die OSM-Datenbank Features gehören, deren Anwesenheit oder Abwesenheit von einem Menschen nicht ohne Hilfsmittel festgestellt werden kann. Elektromagnetische Strahlung eines WLAN-Access-Points, der versteckt irgendwo in einer Wohnung steht, ist so ein Ding. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu FON-FIXME
Sven Rautenberg schrieb: Tobias Wendorff schrieb: Hallo Leute, wieso stecken an den ganzen W-LAN Dingern von FON FIXMEs ? Damit du drüber stolperst und nochmal drauf aufmerksam gemacht wirst, dass diese WLAN-POIs aus einem bislang nicht durch FON autorisierten DB-Import stammen und deshalb wieder gelöscht gehören. Abgesehen davon kann man sich auch trefflich streiten, Gestritten haben wir nicht, aber zumindest sehr viel diskutiert. Nachzulesen im Archiv. Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu FON-FIXME
Hallo Sven, Sven Rautenberg schrieb: Damit du drüber stolperst und nochmal drauf aufmerksam gemacht wirst, dass diese WLAN-POIs aus einem bislang nicht durch FON autorisierten DB-Import stammen und deshalb wieder gelöscht gehören. FIXME finde ich dann nicht so toll ... REMOVEME wäre besser. Abgesehen davon kann man sich auch trefflich streiten, ob in die OSM-Datenbank Features gehören, deren Anwesenheit oder Abwesenheit von einem Menschen nicht ohne Hilfsmittel festgestellt werden kann. Elektromagnetische Strahlung eines WLAN-Access-Points, der versteckt irgendwo in einer Wohnung steht, ist so ein Ding. So kann man W-LAN Abdeckungskarten erzeugen. Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu FON-FIXME
John07 schrieb: Nachzulesen im Archiv. Ich habe echt keine Lust mehr ins Archiv zu gucken, weil da wirklich teilweise wochenlang geschwafelt wird und niemand die Zusammenfassungen ins Wiki stellt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Darstellungsprobleme von Mapnik bei man_made=pier
Moin moin, wieso wird hier: http://www.openstreetmap.org/?lat=54.1805lon=12.088166zoom=18layers=B00FTFTT man_made=pier in Mapnik richtig dargestellt und hier: http://www.openstreetmap.org/?lat=54.18171lon=12.09991zoom=17layers=B00FTF nicht. Osmarender bekommt es in beiden Fällen hin. Ich kann die Ursache hierfür nicht erkennen. Für sachdienliche Hinweise bin ich dankbar. Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Habe eigenes PHP Script für das serve rseitige Rendern von Tiles in ein Preview-Image und suche ...
Sorry die mailings hier duerfen nur 40kb sein. ( n'witz wo es doch um geodaten geht (; ) Hier daher die Links auf meine Beispiel-Renderings: http://www.mobidic.de/osm/3020.png (24Bit) http://www.mobidic.de/osm/3020_1.jpg (minimale JPEG Qualitaet, schnell und ungenau arbeiten, low bandwide) http://www.mobidic.de/osm/3020_16.png (16 Index-Farben) http://www.mobidic.de/osm/3020_64.png (64 Index-Farben) http://www.mobidic.de/osm/3020_72.jpg (mittlere JPEG Qualitaet) ag ... und der Text meiner 'geblockten' email ... Hi klar, hier ein Ausschnitt aus (Tiles) Zoomstufe 6, mit einem TTF bzw. Vektorfont darueber, in verschiedenen Darstellungsqualitaetet (Farbtiefen/Dateiformat). Ich habe einige Layout-Funktionen schon realisiert, wie das Einsetzen von graphischen Text (Linien, Punkte u. Polygone), sowie die Aenderung der Farbtiefe und des Dateiformates (PNG/JPG/GIF) Das Aendern der Farbtiefe, zB bei JPG auf den niedrigsten wert (1), sehe ich dann als vorteilhaft an, wenn man an einer Karte arbeiten moechte aber eben nicht die noetige Bandbreite hat. So kann man relativ schnell, aber eben auch relativ ungenau, eine Karte mit zusaetzlichen Infos/Punkten befuellen (zB Klick und Aktualisierung per xajax). Das meine ich auch, wenn ich von Traffic-Reduzierung spreche. Den Traffic auf den Server umlenken ? - eher nicht - ich lasse den Server zu Anfang nur mehr arbeiten. Da aber alle generierten Ansichten g'cached werden, hat jeder Nutzer spaeter auch einen individuellen Cache, wie bei google maps, so dass der Server, nach einiger Zeit, immer weniger ausliefern muss, je nach 'Angewohnheit' des Users. Das meine ich, wenn ich von Traffic-Reduzierung spreche. Dass auch ein angepasstes Dateiformat dazugehoert, wie zB die autom. Ermittlung der notwendigen Farbtiefe einer Karte, die ausgeliefert werden soll, ist natuerlich auch ein Teil meiner Ueberlegungen. Kurz anstatt mehrere Anfragen an den Server, die auf mehrere PNG-Dateien gehen, will ich eine Anfrage, die entweder auf den User-Cache verweist oder etwas neues generiert, dieses aber nur einmal ausliefert (als eine Datei). Das mit dem 'rudimentaeren' schaue ich mir gleich mal an. Danke. Ist Perl, als Render-Technik, in diesem Bereich denn derzeit noch staerker verbreitet ? AndreasG Tobias Wendorff schrieb: Hallo AndreasG, [EMAIL PROTECTED] schrieb: Ich habe ein eigenes PHP Script für das serverseitige Rendern von Tiles zu einem einzigen Preview-Image geschrieben, um den Traffic zwischen einem Map-Tile Server und dem Client/Browser zu reduzieren (gebe es gerne weiter). Würde gerne mal ein solches Image sehen. Welches PHP-Script Beispiel ist derzeit verfuegbar, um Openstreetmap-Daten in (PNG-)Tiles zu rendern ? http://wiki.openstreetmap.org/index.php/Rendering Alle aber nur sehr rudimentär. Mein aktuelles Ziel: Den Traffic zwischen Map-Tile Server und Client um 2/3 reduzieren und einen Style-Renderer zwischenzuschalten, der das Layout der Karte grundlegend anpassen soll (zB ueber ein zugeordnetes CSS-Stylesheet). Also lenkst Du den Traffic eigentlich nur um? Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Openrouteservice fürs Fahrrad
Am 8. September 2008 17:35 schrieb Wolfgang van Oorschot [EMAIL PROTECTED]: Am 08.09.2008 um 15:49 schrieb Hatto von Hatzfeld: Wolfgang van Oorschot wrote: Am 08.09.2008 um 11:22 schrieb Martin Koppenhoefer: [zu Einbahnstraßen mit Erlaubnis für Fahrräder in Gegenrichtung] wie sollte man das denn taggen? bicycle=opposite? access:bicycle=both? oneway:bicycle=no? Ist nicht cycleway oposite_lane Ein Radfahrstreifen (cycle lane) entgegen der Fahrrichtung einer Einbahnstraße. http://wiki.openstreetmap.org/index.php/De:Map_Features#Fahrradwege genau für diesen Fall gedacht? cyclceway=opposite_lane ist für eine auf dem Boden sichtbar markierte Fahrspur für den in Gegenrichtung fahrenden Radfahrer. Fehlt dieser (und ist also nur durch Zusatzschilder klargestellt, dass hier Radfahrer auch entgegen der Richtung der Einbahnstraße fahren dürfen), dann ist cycleway=opposite die richtige Kennzeichnung. Ok soweit verstanden. Ich hoffe ihr seht das nicht als Thread kapern, aber da hier ja die Radwegprofis versammelt zu sein scheinen erlaube ich mir noch eine Frage aus meiner Praxis. Innerörtliche zweispurige Straße - auf der einen Seite Radweg auf der Fahrbahn durch Markierung gekennzeichnet. Auf der Gegenseite baulich abgesetzter Radweg. Ich finde keine Tags die dieses Szenario erfassen würden. Gruss Wolfgang baulich abgesetzten Radweg in jedem Fall getrennt mappen (eigener way, highway=cycleway, und darauf achten, dass er an *allen* Möglichkeiten zu wechseln auch diese Verbindungen hat fürs Routing), den anderen wie oben beschrieben als tag an die Straße. Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Darstellungsprobleme von Mapnik bei man_made=pier
Hallo, Falk Zscheile [EMAIL PROTECTED] writes: wieso wird hier: http://www.openstreetmap.org/?lat=54.1805lon=12.088166zoom=18layers=B00FTFTT man_made=pier in Mapnik richtig dargestellt und hier: http://www.openstreetmap.org/?lat=54.18171lon=12.09991zoom=17layers=B00FTF nicht. Osmarender bekommt es in beiden Fällen hin. Ich kann die Ursache hierfür nicht erkennen. Für sachdienliche Hinweise bin ich dankbar. kann das eventuell sein, dass Mapnik man_made=pier gar nicht darstellt aber access=private? Letzteres ist bei der erst genannten Karte vorhanden. Viele Grüße Sebastian Waschik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Treffen mit dem Vermessungs- Katasteramt Dortmund
1. Generell wird intern darüber diskutiert, WMS-Dienste bereitzustellen, aus denen wir Informationen ableiten können (Tempo 30 Zonen, Radwege). nicht schlecht, wenn die Daten stimmen erspart einem das ne Menge Mühe 2. Es wird überlegt, uns Straßenkreuzungspunkte zu überlassen, an denen wir unsere GPS-Tracks korrigieren bzw. orientieren können. großartig, allerdings schaffen wir das m.E. im Rahmen unserer Genauigkeit auch mit dem GPS. 3. Eine Übernahme von Stadt-/Stadtteil-Grenzen ist problematisch, da eine Grenzverschiebung in unseren Daten kommunal-politische Konflikte auslösen könnte. verstehe ich nicht, wir können ja auch so nach Belieben Grenzen einzeichnen. Die Grenzen, die die uns geben würden, wären ja vermutlich richtig, und wenn sie jemand ändert sind es nicht mehr deren Grenzen. :( 5. Ein Joint-Venture wurde angedacht: Die Stadt gibt uns Informationen und wir geben dafür Informationen zurück. Als Beispiel wurden Informationen über Barrierefreiheit genannt. Voraussetzung wäre allerdings ein Verein, der dann auch haftbar gemacht werden kann (na das wird jetzt wieder eine Diskussion entfachen...). haftbar wird sich hier m.E. keiner machen wollen, Garantien geben ja nicht mal die großen Kommerziellen ab. Bei uns bekommt man die Infos nach bestem Wissen und Gewissen sowie kostenlos, mehr wird wohl nicht gehen. Ausser ein paar Mapper haben Lust, anstatt zu mappen zu kontrollieren. Viele Grüße Tobias ps: In der Zukunft wird die Stadt Dortmund ein neues Informationssystem für die Bürger einführen, welches auf OpenLayers basiert. habt ihr auch darüber gesprochen, z.B. Gebäude aus der ALK zu importieren? Wie haben sie sich dazu positioniert? Vielen Dank für Deine Mühen und Dein Engagement, hoffentlich lehnen die sich noch ein bisschen mehr aus dem Fenster als nur 30-Zonen und ein paar Kreuzungen. Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] eigene Luftbilder?!
Am 8. September 2008 17:51 schrieb Tobias Wendorff [EMAIL PROTECTED]: Hallo Markus, Markus schrieb: aber sie bräuchten halt eine Art Arbeitsanweisung: - Flughöhe/Brennweite/Auflösung - Flugmuster - Technisches (wie man die Kamera aus dem Fenster hält oder so) - ... nicht, dass ich praktische Erfahrungen habe, aber die Auflösung sollte man vermutlich maximal wählen, Brennweite möglichst groß (also Tele) und Flughöhe daher auch hoch. Das sollte die Verzerrungen gering halten. Ausserdem kurze Belichtung, damit das Bild nicht verwackelt. Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hünengrab taggen ?
2008/9/8 Torsten Leistikow [EMAIL PROTECTED] Birgit Nietsch schrieb: Wäre historic=megalithical_site nicht passender? Das ließe sich dann mit dolmen=yes, barrow=yes oder menhir=yes präzisieren (je nachdem, was es ist). Und ein international auf Landkarten gebräuchliches Symbol für derartige Gebilde gibt es auch schon: den schiefen, dreibeinigen Steintisch. Im Prinzip waere das wahrscheinlich passender. Aber das beste Tag nuetzt einem nichts, solange es kein Renderer oder Kartenkonverter auswertet. Deshalb verfolge ich erstmal den Ansatz, soweit moeglich/sinnvoll erstmal moeglichst viele Daten mit den bestehenden/gebraeuchlichen Markierungen zu erfassen. Schoen-Machen kann man es dann spaeter noch mal. In diesem Fall koennte man ja das etablierte historic=archaeological_site verwenden und mit den dolmen=yes usw. erweitern. Dann muesste eigentlich allen gedient sein. Gruss Torsten soweit ich das sehe wird das historic=archaeological_site auch nicht von Osmarender oder Mapnik berücksichtigt. Von daher kannst Du gleich was nehmen, was die Sache gut beschreibt. Ich finde historic=megalithical_site oder ggf. leicht anders (muss ja nicht gleich ne site sein) ganz OK. Zur systematischen Klassifizierung empfehle ich Dir Rücksprache mit Roman Grabolle, dem bekannten OSM-Archäologen. Siehe auch hier: http://wiki.openstreetmap.org/index.php/WikiProject_Germany/Kulturdenkmale Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Treffen mit dem Vermessungs- Katasteramt Dortmund
Martin Koppenhoefer schrieb: 1. Generell wird intern darüber diskutiert, WMS-Dienste bereitzustellen, aus denen wir Informationen ableiten können (Tempo 30 Zonen, Radwege). nicht schlecht, wenn die Daten stimmen erspart einem das ne Menge Mühe Die Daten sind sogar für unser Modell zu genau. Die Radwege sind beiseitig erfasst und nicht mittig, wie bei uns. 2. Es wird überlegt, uns Straßenkreuzungspunkte zu überlassen, an denen wir unsere GPS-Tracks korrigieren bzw. orientieren können. großartig, ^^ Das sehen leider ein paar Leute anders... allerdings schaffen wir das m.E. im Rahmen unserer Genauigkeit auch mit dem GPS. Es ging um Korrektur der GPS-Daten. Gerade in Großstädten wandert das Signal gerne mal durch Gebäude :-) habt ihr auch darüber gesprochen, z.B. Gebäude aus der ALK zu importieren? Wie haben sie sich dazu positioniert? Vielen Dank für Deine Mühen und Dein Engagement, hoffentlich lehnen die sich noch ein bisschen mehr aus dem Fenster als nur 30-Zonen und ein paar Kreuzungen. Wir haben die Google-Offensive mit den Hausnummern erwähnt. Als bereits da ein Raunen und Kopfschütteln durch den Saal ging, habe ich sowas Konkretes erst gar nicht erwähnt :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] eigene Luftbilder?!
Martin Koppenhoefer schrieb: nicht, dass ich praktische Erfahrungen habe, aber die Auflösung sollte man vermutlich maximal wählen, Brennweite möglichst groß (also Tele) und Flughöhe daher auch hoch. Das sollte die Verzerrungen gering halten. Ich könnte mir vorstellen, dass gerade durch Tele die Verzerrungen, die durch die Fluggeschwindigkeiten entstehen, stark vergrößert werden. Ausserdem kurze Belichtung, damit das Bild nicht verwackelt. In der Tat - lieber falsche Belichtung, als Unschärfe. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] eigene Luftbilder?!
hallo Martin Koppenhoefer schrieb: [EMAIL PROTECTED]: Hallo Markus, Markus schrieb: aber sie bräuchten halt eine Art Arbeitsanweisung: - Flughöhe/Brennweite/Auflösung - Flugmuster - Technisches (wie man die Kamera aus dem Fenster hält oder so) - ... nicht, dass ich praktische Erfahrungen habe, aber die Auflösung sollte man vermutlich maximal wählen, Brennweite möglichst groß (also Tele) und Flughöhe daher auch hoch. Das sollte die Verzerrungen gering halten. Ausserdem kurze Belichtung, damit das Bild nicht verwackelt. und möglichst senkrecht nach unten fotografieren, weil die entzerrung/referenzierung sonst bis zur unmöglichkeit schwierig wird. habe mal tests von hohen gebäuden gemacht (und mit grass, gdal-tools und metacarta experimentiert): ab etwa 5° abweichung der optischen achse von der senkrechten wird es wirklich schwierig bis - wie gesagt - unmöglich... grüße hermann ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] GPS-Geräteempfehlung
Lars Schimmer schrieb: Ich bin mit meinem Garmin eTrex Legend HCx recht zufrieden. Ist genau genug, klein, handlich, ausreichend Batterie Laufzeit, kann OSM Map anzeigen,... Nur die Höhendaten sind halt etwas ungenau, dafür dann den Vista HCx nehmen. Kosten um die 200 Euro/Stück. Ich habe so ein Vista HCx, bin sehr zufrieden damit. Mit dem GPS bekommt man selbst hier im Schwarzwald oft eine Genauigkeit von weniger als 2m Abweichung. Außerdem hat es ein Barometer, daß wenn man es kalibriert dann bessere Höhendaten liefert. Philipp ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Habe eigenes PHP Script für das serve rseitige Rendern von Tiles in ein Preview-Image und suche ...
Hallo, [EMAIL PROTECTED] wrote: Ist Perl, als Render-Technik, in diesem Bereich denn derzeit noch staerker verbreitet ? Wenn Du performant aus Rohdaten Grafiken errechnen willst (auf einem oeffentlichen Server), kommst Du m.E. um C/C++ nicht herum, und brauchst natuerlich auch direkten Datenbankzugriff. Dein Ansatz hat den Vorteil, dass Du ihn als Proxyserver zwischen einem normalen Tileserver und dem User fahren kannst, aber vermutlich wird Dein Cache wenig nuetzen, denn die User scrollen ja auf der Karte rum, und Du musst den Cache sofort verwerfen, wenn auch nur ein Pixel nach links geschoben wird oder so - das ist eben die grosse Starke des Tile-Ansatzes, dort muss nur ein Bruchteil des Bildes nachgeladen werden, bei einem Ansatz wie Deinem immer das komplette. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] eigene Luftbilder?!
hermann schwaerzler schrieb: und möglichst senkrecht nach unten fotografieren, weil die entzerrung/referenzierung sonst bis zur unmöglichkeit schwierig wird. habe mal tests von hohen gebäuden gemacht (und mit grass, gdal-tools und metacarta experimentiert): ab etwa 5° abweichung der optischen achse von der senkrechten wird es wirklich schwierig bis - wie gesagt - unmöglich... Kannst du mir mal Beispiele schicken? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu FON-FIXME
Moin Tobias, wieso stecken an den ganzen W-LAN Dingern von FON FIXMEs ? Weil die Koordinaten nicht so die, ähem, ganz große Präzision haben? Ich habe schon welche gelöscht, wo definitiv in etwa 1km Umkreis kein Stromanschluß zu finden ist, also mitten auffem Acker. Abgesehen davon, daß ich diese Daten in OSM für unpassend halte: Wenn die Datenqualität überall so toll ist, wem soll sowas nützen? Rainer -- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sichheitstor in Kanal
Gerhard schrieb: hat jemand eine Idee wie man ein Sicherheitstor an einem Kanal darstellen könnte? Ich würde da ein Polygon mit building=yes und name=Sicherheitstor XY? Den Mittelteil kannste ja auf Layer=1 setzen, weil default... Im Gegensatz zu http://upload.wikimedia.org/wikipedia/commons/2/28/DEK_Datteln_Kanalsperrtor.jpg -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenGeoDB Fehler / Analyse aller places -Objekte für QS-Zwecke
OK, ich habe mir mal die places-Objekte vorgenommen und folgendes rausgefunden:
Features (für DE) gesamt ('city', 'town', 'village', 'suburb', 'locality',
'hamlet') : 39.059
Features mit einem Sekunden-Anteil von 0,15 in X *und* Y: 4844
Das Ergebnis gibt's als Karte unter:
http://mauszeig.files.wordpress.com/2008/09/osm_places.png
rot=Problempunkte, grau=ok
Hintergrund: Anzahl Problempunkte pro Gesamtanzahl (je dunkler desto mehr
Problempunkte)
Eine CSV- oder Excel-Datei der Problempunkte kann ich für QS-Zwecke bei Bedarf
zur Verfügung stellen.
Alex
Alexrk schrieb am 07.09.2008 15:42:
Ich habe eben auch noch mal bei geonames.org nachgeschaut und finde dort
leider
flächendeckend das gleiche Problem :( Obwohl der geonames-Datenbestand viel
umfangreicher als OpenGeoDB zu sein scheint, werden doch die meisten
Koordinaten
nur bis auf Minuten-Genauigkeit angegeben. Das reich sicher für eine grobe
Ortsuche, aber für eine Kartierung reicht das wohl nur bis zum Maßstab 1:1Mio.
Vielleicht könnte man solche Problemfälle in den OSM-Daten automatisch
aufspüren, indem man nach ganzen Minuten sucht?
Alex
Bernd Wurst schrieb am 29.08.2008 19:14:
Hallo.
Am Freitag, 29. August 2008 schrieb Martin Koppenhoefer:
das hoert sich alles eher so an, als ob nicht nochmal reimportiert wuerde.
Der Screenshot ist uebrigens schaurig, die liegen ja alle in einem Raster.
Solche Daten bitte auf keinen Fall importieren.
Auf mich wirkt OpenGeoDB so als wäre da irgendwann mal ordentlich was von
den
Koordinaten abgeschnitten worden. Daher das Raster.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] oberirdische U-Bahn = subway?
Hallo, wie tagged man denn eine oberirdische U-Bahn richtig? Die in München ist teilweise als subway, teilweise als railway getagged. railway ist sie m.E. definitiv nicht, subway ist richtiger von der Erwartung, was da fährt. (andere) Meinungen? Viele Grüße, Andi -- http://home.arcor.de/andreas-barth/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] GPS-Geräteempfehlung
Philipp Klaus Krause schrieb: Mit dem GPS bekommt man selbst hier im Schwarzwald oft eine Genauigkeit von weniger als 2m Abweichung. Und das hast Du wie überprüft? Garr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM - Verbesserungen erwünscht!
Lars Schimmer: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo! Nachdem ich gestern wieder mal unterwegs war, habe ich ein paar GPS Traces von der Ostbahn und weiteren kleinen Ecken östlich von Graz getraced. Dabei ist aufgefallen, das die tatsächliche Bahnstrecke um bis zu 30m von der in OSM abweicht. Da ich die nicht einfach ändern möchte (auch wenn ich meinem Garmin eTrex Legend HCx schon mehr vertraue als der OSM Karte), will ich den User anschreiben, der die Strecke gesetzt hat. Nur wie finde ich den User heraus? MfG, Lars Schimmer Mal ganz abgesehen davon, dass du nicht jedes mal Kontakt mit einem OSM-Nutzer aufnehmen musst, wenn du seine Daten veränderst. Wenn dein GPS-Track mit hoher Genauigkeit aufgenommen wurde, du ihn womöglich gar bei der Rückfahrt nochmals bestätigen konntest, dann verbessere bitte die Daten und setze die Bahnstrecke richtig. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] oberirdische U-Bahn = subway?
Am Dienstag, 9. September 2008 00:02 schrieb Andreas Barth: Hallo, wie tagged man denn eine oberirdische U-Bahn richtig? Die in München ist teilweise als subway, teilweise als railway getagged. railway ist sie m.E. definitiv nicht, subway ist richtiger von der Erwartung, was da fährt. Wie ist eigentlich die S-Bahn auf der Stammstrecke (Hackerbrücke-Ostbahnhof) eingetragen? Da ergibt sich das gleiche Problem nur andersrum. (andere) Meinungen? Ich finde, man sollte es nach dem baulichen Begebenheiten taggen. Da wo U-Bahn oberirdisch railway und da wo S-Bahn unterirdisch subway. Den Rest über Namen oder andere Tags .(U123, S456) Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] tacken getackt?
Hallo, ich vermute mal, dass ich diese Liste noch nicht lang lese, trotzdem wage ich es mal zu fragen: Auf welchen Anlass geht der hier gepflegte Flaschschreibung zurück xyz getackt? -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tacken getackt?
Johann H. Addicks schrieb: Hallo, ich vermute mal, dass ich diese Liste noch nicht lang lese, trotzdem wage ich es mal zu fragen: Auf welchen Anlass geht der hier gepflegte Flaschschreibung zurück xyz getackt? Neographie braucht einfach neue Begriffe! Solange wir lalle mitmachen trägt OSM zur Weiterentwicklung der Sprache bei. Gruß, Stephan. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Habe eigenes PHP Script für das serve rseitige Rendern von Tiles in ein Preview-Image und suche ...
Der sichtbare Ausschnitt ist schon der ausgewaehlte, da wird also nicht mehr geschoben, sondern nur noch 'reingemalt'. Datenbankzugriff kann ich mir natuerlich selber machen, indem ich die Tiles der Zoomstufe 17 (meine gewaehlte max. Detailtiefe) selber hoste, wie zB auch den Datensatz von geonames.org Aus den Tiles der Zoomstufe 17 generiere ich, bei Bedarf, alle kleineren Groessen, was den Platz auf dem Server erstmal etwas frei haelt. Zusaetzlich limitiere ich die Zoomstufe auf 6 'sinnvolle' Masstaebe (Kontinent, Land, Region, Stadt, Haus, Mensch, das entspricht. 2000km, 500km,100km, 5km, 500m, 100m) Ich ziehe mir jetzt einfach die Tiles der Zoomstufe 17 direkt von OSM-Server, nur frage ich mich natuerlich, wie bekomme ich Tiles 'ohne die Geonames' drauf, deren 'Texte' ich ja gerne selber setzen/rendern moechte ? Gibt es eine Tile-Satz auf dem OSM-Server der weder Strassenlinien noch Namen enthaelt, sondern nur die Shapes des Laender/Kontinenten, Fluesse etc. ? Fragen ueber Fragen ( : ag Frederik Ramm schrieb: Hallo, [EMAIL PROTECTED] wrote: Ist Perl, als Render-Technik, in diesem Bereich denn derzeit noch staerker verbreitet ? Wenn Du performant aus Rohdaten Grafiken errechnen willst (auf einem oeffentlichen Server), kommst Du m.E. um C/C++ nicht herum, und brauchst natuerlich auch direkten Datenbankzugriff. Dein Ansatz hat den Vorteil, dass Du ihn als Proxyserver zwischen einem normalen Tileserver und dem User fahren kannst, aber vermutlich wird Dein Cache wenig nuetzen, denn die User scrollen ja auf der Karte rum, und Du musst den Cache sofort verwerfen, wenn auch nur ein Pixel nach links geschoben wird oder so - das ist eben die grosse Starke des Tile-Ansatzes, dort muss nur ein Bruchteil des Bildes nachgeladen werden, bei einem Ansatz wie Deinem immer das komplette. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu FON-FIXME
Rainer Knaepper schrieb: wieso stecken an den ganzen W-LAN Dingern von FON FIXMEs ? Weil die Koordinaten nicht so die, ähem, ganz große Präzision haben? Das Google-Adresscoding ist halt nicht besser. ;-) -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tacken getackt?
Hallo, Johann H. Addicks wrote: Auf welchen Anlass geht der hier gepflegte Flaschschreibung zurück xyz getackt? Wer ausser Jan Tackenbeck schreibt das denn noch ;-)? Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tacken getackt?
Johann H. Addicks schrieb: Hallo, ich vermute mal, dass ich diese Liste noch nicht lang lese, trotzdem wage ich es mal zu fragen: Auf welchen Anlass geht der hier gepflegte Flaschschreibung zurück xyz getackt? Weil irgendwelche ... (ich möchte das aus meiner Sicht passende Wort hier nicht hinschreiben) der Meinung sind das es schick ist, sich tolle neue Worte auszudenken. Natürlich ohne sich darüber im klaren zu sein, daß dies insbesondere Neulinge nur den ohnehin nicht einfachen Einsteig noch mehr als notwendig verwirrt, wenn drei Leute fünf Begriffe für die gleichen Sachen verwenden :-((( Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] qualitätsoffensive - nicht angebunden e straßen - teilweise katastrophale datenqualität
Sebastian Waschik schrieb: dann setze doch an die Knoten die Kreuzungen sind ein Straßenstummel oder setze ein FIX-Tag an den Knoten. Kann sein, dass ich da schonmal unbewusst was verschoben habe, als ich den Straßenverlauf verbessert habe, da die Tracks teilweise richtig mies sind. Ich mache das in der Regel so, dass ich einfach ein kurzes Stück der abzweigenden Straße ansetze. Dann ist jedem sofort klar, dass da etwas ist. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
