Re: [OSM-dev] world wide PBF exports corrupt
Hi Paul, Hi Simon, this clarifies the daily vs. weekly and thanks for the osmupdate tool, should I add this to the wiki? And is there a tool where I can verify the new PBF or is my only guess the size? Regarding the corruption indeed osm looks good, but the mirrors don't: ftp://ftp.spline.de/pub/openstreetmap/pbf/ (only 17gb) http://ftp.snt.utwente.nl/pub/misc/openstreetmap/ (only 16gb) http://ftp.heanet.ie/mirrors/openstreetmap.org/pbf/ (only 6gb) over 1 week old: http://ftp.osuosl.org/pub/openstreetmap/pbf/ http://ftp5.gwdg.de/pub/misc/openstreetmap/planet.openstreetmap.org/pbf/ So I think there is something wrong in the common toolchain (?). I would prefer to use mirros to take off load from the main servers and have more local ones. Kind Regards, Peter. -- GraphHopper.com - Fast Flexible Road Routing On 20.10.2014 01:55, Paul Norman wrote: On 10/19/2014 3:04 PM, Peter K wrote: it looks like all pbf export servers I know have no recent or corrupt pbf exports (small file size of 17gb or 6gb instead of 27gb): http://wiki.openstreetmap.org/wiki/Planet.osm Is this a known issue of some export tool? Or do you know an alternative? http://planet.openstreetmap.org/pbf/planet-141015.osm.pbf is 26GB, which looks normal to me. The mirrors are that - mirrors, not export servers. Before using the planet file, you can run Osmupdate[1] on it, which takes under an hour on most hardware and will give you an up to the hour version of the OpenStreetMap database. (Also it looks like there are no daily export servers anymore?) We've never had planet exports generated daily. If you need a complete planet file every day, the standard means is to download one and then update it every day, which uses far less bandwidth than downloading a new one. This is what is done for taginfo, and what external services like OSRM do. [1]: http://wiki.openstreetmap.org/wiki/Osmupdate ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
[OSM-dev] world wide PBF exports corrupt
Hi there, it looks like all pbf export servers I know have no recent or corrupt pbf exports (small file size of 17gb or 6gb instead of 27gb): http://wiki.openstreetmap.org/wiki/Planet.osm Is this a known issue of some export tool? Or do you know an alternative? (Also it looks like there are no daily export servers anymore?) Regards, Peter. -- GraphHopper.com - Fast Flexible Road Routing ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [osmosis-dev] Example code for PBF reading
Osmosis just uses this library, right? I mean, it is a nicely packaged version of LGPLed OSM-binary: https://github.com/openstreetmap/osmosis/tree/master/osmosis-osm-binary Use it in maven via: dependency groupIdorg.openstreetmap.osmosis/groupId artifactIdosmosis-osm-binary/artifactId version0.43.1/version /dependency Regards, Peter. On Di, Mär 18, 2014 at 01:29:57 -0600, Martijn van Exel wrote: Are there any examples known to you that use the osmosis code in another project? I am specifically interested in using the PBF reading code. Or is there perhaps an easier way to add OSM PBF reading to my own (Java) project? There is some example PBF reading code in the OSM-binary repository https://github.com/scrosby/OSM-binary/blob/master/src.java/crosby/binary/test/ReadFileExample.java Also I think mkgmap (http://www.mkgmap.org.uk/) has its own PBF reading code based on OSM-binary. How good those implementations are, I don't know. Reading PBF files is not so simple, there are undocumented details that can trip you up. So using either of these might be more difficult than with Osmosis. Jochen -- GraphHopper.com - Fast Flexible Road Routing ___ osmosis-dev mailing list osmosis-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/osmosis-dev
Re: [OSM-dev] GSOC 2014 - Introduction
You could spread the word so that there will be more OSM projects available for gsoc ;) https://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2014/Project_Ideas Regards, Peter. Hello all, I am a MS by research student(Computer Science) at Lab for Spatial Informatics, International Institute of Information Technology, Hyderabad - India. I am interested in taking part in GSOC 2014 and developing for OSM projects. What would be the next steps to get involved and contribute? Thanks and Regards, Varun Saraf Lab for Spatial Informatics International Institute of Information Technology Hyderabad, India +91-90308-74699 ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
[OSM-dev] GraphHopper Maps 0.2
Hi there, yesterday we released the second public version of our fast and Open Source routing engine called GraphHopper in 100% Java. You can also try our web application http://graphhopper.com/maps/ with world wide coverage. See the full anouncement here. http://karussell.wordpress.com/2013/11/25/releasing-graphhopper-0-2-further-faster-road-routing/ Let me know if you encounter problems or if you have questions! Kind Regards, Peter. ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Standard for Map Key
Thanks Yves for the pointer! Also the cloudmade support brought another project to my attention: http://humangeo.github.io/leaflet-dvf/ See below where it reads: /Legends - Useful for visually informing users about the dynamic styles associated with your L.DataLayer instances/ and /L.Control.Legend - Add this control to your map to automatically display a dynamic legend for any L.DataLayer based instance that you add to your map/ Regards, Peter. I spent some time 3 years ago on the subject, and came out with that: https://github.com/yvecai/RenderLegend Unfortunately, the demo website that was showing mapkeys for various styles, in various languages, and changing when zooming the map is not anymore. It's not usefull to try to create the legend automatically from a style. It was in xml at the time, but I doubt today's css change a lot in this matter: you'll need a full fledged sql parser. I ended up with this as the entry point: https://github.com/yvecai/RenderLegend/blob/master/legend_compact.xml This kind of file should probably come in 2 version: a short one and a to-be-complete one. Hope this helps, Yves On 09/16/2013 11:55 AM, Peter K wrote: Hi, is there a kind of a standard or suggestion on how to retrieve the map key? Like an http API or a leaflet plugin? On osm.org there is only the 'map key' data available for the default layer in the right box. And not all details are given like here: http://wiki.openstreetmap.org/wiki/DE:Map_Features Someone knows some open source effort for more details and for support of the various providers like mapquest, osm.de, cloudmade, ...? Kind Regards, Peter. ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev . ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Standard for Map Key
Hi, is there a kind of a standard or suggestion on how to retrieve the map key? Like an http API or a leaflet plugin? On osm.org there is only the 'map key' data available for the default layer in the right box. And not all details are given like here: http://wiki.openstreetmap.org/wiki/DE:Map_Features Someone knows some open source effort for more details and for support of the various providers like mapquest, osm.de, cloudmade, ...? Kind Regards, Peter. ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Standard for Map Key
Hi!
Peter Wendorff:
Hi,
as far as I know all map keys are created by hand.
I'm not sure what you refer to exactly, but basically I see two things
which would be great to have:
1) some kind of standard to retrieve a map key for a given tile set;
e.g. tile-URL is tile.openstreetmap.org/{z}/{x}/{y}.png, then search for
map key information (in a structured format, not html) at
tile.openstreetmap.org/mapkey.xml
As far as I know there is nothing like that yet.
Yes, that was what I meant and I think Tom already mentioned similar stuff
2) it would be really great to have some automatic map key generation
out of the style files. For Mapnik that's incredible ugly as mapnik does
not have any semantic connection between e.g. highway casing, fill and
label. For CartoCSS (which is used since a while for the default style)
this might be possible in parts.
In any case it would require additional information like which label to
use for a particular feature in the map key, which items should NOT be
displayed (as Tom mentioned) or in which order items should be displayed.
Probably it is easier to generate a list with all things and
select/order it manually.
Andy Allan:
... I've been developing something that does this.
I aim to make it configurable enough to recreate what we have at the
moment, and to make it easy/feasible for me to create legends for my
other styles, and to add more functionality like sprite images. The
ultimate goal is to be able to create legends like the Ordnance survey
have - for those not familiar with them, have a look at
https://github.com/gravitystorm/mapnik-legendary and check out the way
that the railway crossings in the 1:25,000 or water features in the
1:50,000 maps are shown for some inspiration.
Overall, I have no intention of manually updating the legend that we
have at the moment. If anyone wants to take it on then feel free, but
my efforts are going into mapnik-legendary
Nice! How does the output look like at the moment? Identical to what Tom
mentioned? At the end it would make no difference if this file is
manually created or by a script. But you should define (with Tom?) a
'standard map key' format!?
IMO a file like the key.yml is all we need and supporting an image
sprite is easy possible via a lookup by the name/id (plus ignoring the
provided png).
Kind Regards,
Peter.
Am 16.09.2013 11:55, schrieb Peter K:
Hi,
is there a kind of a standard or suggestion on how to retrieve the map
key? Like an http API or a leaflet plugin? On osm.org there is only the
'map key' data available for the default layer in the right box. And not
all details are given like here:
http://wiki.openstreetmap.org/wiki/DE:Map_Features
Someone knows some open source effort for more details and for support
of the various providers like mapquest, osm.de, cloudmade, ...?
Kind Regards,
Peter.
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Default map style on osm.org
Hi there, I know that this is highly subjective: But why has the default map style to be that ugly? I don't mean it as a rant, I know how difficult it is to create something like this. I only say that it is 'ugly' because I know there are a lot better and several alternatives. What do I mean with 'ugly'? I mean, besides the ugly bing-magenta for country lines and some texts the style is very confusing - too many unimportant information are packed on especially the higher zoom levels (smaller than 12). Or the contrast to see main roads is just too low. Not sure. So, why is not something better used like the style from openstreetmap.de http://openstreetmap.de/karte.html, mapquest open or cloudmade? I know I can change that easily in 'Map Layers' - but why is this the default? Or at least: will this default style be further developed and improved? It is especially bad for people new to OSM which almost always think: uh this map from OSM is ugly. I keep using goo... Kind Regards, Peter. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Default map style on osm.org
Hi Andy, hi Frederik, hi Maarten, I know that this is highly subjective: But why has the default map style to be that ugly? I don't mean it as a rant, I know how difficult it is to create something like this. I only say that it is 'ugly' because I know there are a lot better and several alternatives. What do I mean with 'ugly'? I mean, besides the ugly bing-magenta for country lines and some texts the style is very confusing - too many unimportant information are packed on especially the higher zoom levels (smaller than 12). Or the contrast to see main roads is just too low. Not sure. As you say: it's highly subjective. I have no problem with the default OSM style at all. The only thing is that from zooms 8 and lower I think the landuse may be less prominent. Some time ago someone showed a new lowzoom renderer that looked rather nice. I also don't see a big difference between the .de and the default map. The two differences are that .de has red-yellow motorways (in the style of a lot of paper maps) and that the general theme is less red and more green. Yes, .de and default are not that different. But I think .de is one step into a good direction with somehow more contrast colours. And yes, the landuse is also one thing which is confusing to me (and others). If you follow these lists for a while (and possibly the enhancement requests filed in trac or github for the map style) then you will see that we have many many people keen on adding more and more detail to the map. Exactly that is what is the problem: too detailed on overview zoom levels. But it is good to hear that there will be progress on the style - not only on the internals (which is of course really great - see below). We're trying to keep the default map usable but at the same time it is also used by mappers to get feedback on their edits; Ok, that is an argument. But I expect mappers to be able to switch the layer in their settings in comparison to an average 'luser'. See the following video for some background regarding the current state of the main map style http://vimeopro.com/openstreetmapus/state-of-the-map-us-2013/video/68093876 Since the conference, the new openstreetmap-carto stylesheets are now live, and many small improvements are starting to show up. I know. This is a really nice direction and lots of possibilities are opened via this. But I've always heard/read that the style has to stay the same. Could it be an option with Carto-CSS (in the future) that the default style is less detailed and mappers can enable this if they want? Who can decide and develop this in the future? Regards, Peter. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Default map style on osm.org
Am 28.08.2013 17:33, schrieb Andy Allan: On 28 August 2013 16:26, Holger Jeromin mailgm...@katur.de wrote: I think the rewrite in carto wanted to maintain the visual result to be sure to be able to switch the main rendering. Otherwise the switch could be stopped by some for visual reasons. Good point - that's probably the source of the confusion. Yeah, that was the source of confusion. Also it is nice to hear that you're open to change and some people agree with me that osm.org needs one style for the normal user and one for the mapper. The primary goal of the default style is to expose as much of the OSM data as possible. I see osm.org as the main reference for OpenStreetMap. And everytime I suggest friends to have a look at this great source of information I hear it is not clear or even ugly. Also they miss a router but that is another topic ;) I think (and it would probably be also in the sense of all mappers) that OSM should gain even more (at)traction. And to do this one simple thing could be to improve the default style. As Frederik mentioned, the default style is a mapper's map. It's there to provide instant feedback to mapping efforts. Why? Who decides this? Why not a normal user map as default and the mapper can choose its own preferred layer? This decission process is not clear to me here at OSM. Not to bash this and the community of course! Is there some process how to establish consent? Could it be probably easier for all to handle it like the Apache Foundation ... ? Regards, Peter. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] The new link on the OSM map
As there are redirects I do not see an issue here and I really like the progress which is going on! ... why not introduce a policy how to make changes to osm.org to avoid 'social' or other issues in the future? I would suggest instead of discussion everything on the dev mailing list, do it like it is done in the Apache Foundation per issue or per release: * define: who is core committer to openstreetmap-website (or any other project of OSM) * for every issue, release etc the committers vote: http://www.apache.org/foundation/voting.html * To become a new commiter or get voting rights you have to be included from existing committers Once voted (or before?) one could 'inform' on the dev list that some breaking changes could occur after deploying it. This way everyone could join the discussion but only a subset of them decide, which speeds up development but avoids a 'restricted horizon'. What's more as this was done unannounced (no, an internal issue tracker is not an announcement), all these applications are failing now as a surprise for their users. I disagree here. Developer have to decide. osm.org should be pushed even faster forwards. I don't think that github is internal as you can easily watch the discussion and stay informed via email. Regards, Peter. On Thu, Aug 8, 2013 at 1:56 PM, Maarten Deen md...@xs4all.nl mailto:md...@xs4all.nl wrote: I'm sorry, but IMHO this is yet another step backward. I don't know how it's hard to see that this is an offensive liner to anyone who works on openstreetmap.org http://openstreetmap.org. Sorry. yet another alludes to a steady decline brought about by people who keep your web site up. It's exactly the passive aggressive stuff that gets us into long and _exhausting_ tit for tat arguments on mailing lists all the time. Let's have more fun together. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Routing on OSM.org (was GraphHopper Maps 0.1)
Although I do very much hope that something like this will eventually make its way onto osm.org. Kai I've created an issue for it: https://github.com/openstreetmap/openstreetmap-website/issues/381 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] GraphHopper Maps 0.1
I took the liberty of comparing the result on that page to the direct call. How realistic are the results? If I run a route e.g. from Heroldsberg to Biograd, I get greatly different times: http://apmon.dev.openstreetmap.org/routing: 9,5s directly on http://graphhopper.com/maps/: 0.017s So it seems that the result of the compare page is off by a factor of more than 500 times. Why? bye, Nop The actual requests get sent from the server backend on the osm dev server (rails app) and are then transcoded from json to kml before getting passed on to the user. Unfortunately, the dev servers rails system seems to be incredibly slow! Even just simply loading the pages takes a long time. Would be nice if you could somehow include the actual response size and time in the output to have a feeling for that too. Would you mind to print an error message if some vehicles or routing types are not supported instead of printing results for the default? Eg. graphhopper does not support shortest in the web API and OSRM does not support foot etc PS: there seems to be a small bug when I enter a new location so I have to click twice on 'find route'. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] GraphHopper Maps 0.1
Hi there, yesterday we released the first public version of our fast and Open Source routing engine called GraphHopper. This could be especially interesting for Java developers. You can also try our web application http://graphhopper.com/maps/ with world wide coverage. See the full anouncement here. https://karussell.wordpress.com/2013/07/22/graphhopper-maps-high-performance-and-customizable-routing-in-java/ Let me know if you encounter problems or if you have questions! Regards, Peter. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] GraphHopper Maps 0.1
Thanks! I've created an issue for it! Peter. Hi Peter, Nice to see new stuff. Works nice in long distances. I noticed that it does not like roads with tram rails. (highway=*, railway=tram) See http://graphhopper.com/maps/?point=56.949977%2C24.120226point=56.952645%2C24.122061 Viesturs On Tue, Jul 23, 2013 at 10:22 AM, Peter K peat...@yahoo.de mailto:peat...@yahoo.de wrote: Hi there, yesterday we released the first public version of our fast and Open Source routing engine called GraphHopper. This could be especially interesting for Java developers. You can also try our web application http://graphhopper.com/maps/ with world wide coverage. See the full anouncement here. https://karussell.wordpress.com/2013/07/22/graphhopper-maps-high-performance-and-customizable-routing-in-java/ Let me know if you encounter problems or if you have questions! Regards, Peter. ___ dev mailing list dev@openstreetmap.org mailto:dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] GraphHopper Maps 0.1
Hi Eugene, thanks for your feedback! 1. It seems turn restrictions are not taken into account in the routing? yes 2. It seems that the internal routing graph has too few nodes from where you can start or end. I think this might be a result of the optimizations you have performed to make the router fast. So if you wanted to route to a POI along a one-way street, you might get routed to the point at the end of the one-way street and the route does not pass through that one-way street. Here's an example to make the second issue clearer: http://graphhopper.com/maps/?point=14.557141%2C121.021051point=14.559306%2C121.020455 Indeed. This will be fixed with the next release as it is not only important for car but also for hiking etc: https://github.com/graphhopper/graphhopper/issues/27 Regards, Peter. Hi, Here's some feedback: 1. It seems turn restrictions are not taken into account in the routing? 2. It seems that the internal routing graph has too few nodes from where you can start or end. I think this might be a result of the optimizations you have performed to make the router fast. So if you wanted to route to a POI along a one-way street, you might get routed to the point at the end of the one-way street and the route does not pass through that one-way street. Here's an example to make the second issue clearer: http://graphhopper.com/maps/?point=14.557141%2C121.021051point=14.559306%2C121.020455 I would expect the route to pass along the one-way street. Eugene On Tue, Jul 23, 2013 at 3:22 PM, Peter K peat...@yahoo.de mailto:peat...@yahoo.de wrote: Hi there, yesterday we released the first public version of our fast and Open Source routing engine called GraphHopper. This could be especially interesting for Java developers. You can also try our web application http://graphhopper.com/maps/ with world wide coverage. See the full anouncement here. https://karussell.wordpress.com/2013/07/22/graphhopper-maps-high-performance-and-customizable-routing-in-java/ Let me know if you encounter problems or if you have questions! Regards, Peter. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] GraphHopper Maps 0.1
Hi Frederik, I read that I can run GraphHopper with or without CH. this is true. Currently you have the choice between A*/Dijkstra (simple, bidirectional, bidirectional CH) or is the speed profile baked into the routing graph The online demo is CH based and requires 3*16GB. If you'd use a none-CH graph you would have all the flexibility BUT as you already said you have to take care that the shortest path tree won't eat all the available RAM (e.g. use a memory bound dijkstra). Or you'll have to make compromises in the quality/'exactness' of the routes. With graphhopper you have the choice. If you only need a rather smallish area like bavaria (or even germany can work with tuning) you don't need CH. All that was said under the fact that you are using the in-memory data access method of graphhopper. But you can try graphhopper via a memory mapped data access which is the default for Android and you won't need lots of RAM which could be want you want for the CH-based stuff and multiple profiles. But of course this will slow things down too, but I don't know how much (will still depend on how many RAM is available). Regards, Peter. Hi, On 23.07.2013 09:22, Peter K wrote: yesterday we released the first public version of our fast and Open Source routing engine called GraphHopper. I'd like to understand better where this fits in between the purely A* gosmore and the CH-based osrm. With osrm, it is difficult to have multiple routing profiles on one machine because you have do compile a routing graph for each profile - a world-wide setup for car, bike, foot would take something like 150 GB of memory on the server. With gosmore, this is easy since you only need one routing graph to support a multitude of profiles - not only car, bike, foot, but also motorcycle, HGV, and others. This flexibility comes at a noticeable speed penalty. I read that I can run GraphHopper with or without CH. Does that mean that when I run it without, I get the gosmore-like flexibility to evaluate edges at runtime, or is the speed profile baked into the routing graph (and therefore your demo server needs something like 64 GB of RAM because it has three routing graphs)? Bye Frederik ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] GraphHopper Maps 0.1
The online demo is CH based and requires 3*16GB Forgot to mention that if one would reuse the base graph of ~9GB one could reduce this to something like 25GB (would take a bit development effort) Peter. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] GraphHopper Maps 0.1
Thanks! Hi, this looks like an interesting addition to the set of routing engines already available for OSM data. I was curious to see how it compares in speed and quality of calculated routes to the other engines, so I took the liberty to add it to http://apmon.dev.openstreetmap.org/routing That page allows you to use all of the main routing engines (OSRM, YOURS, Mapquest Open, Cloudmade and now Graphhopper) through a single web interface and therefore allows to compare the calculated routes quite easily and how they behave with the various OSM constructs and tagging schema. I hope adding it was OK with you. If not, then I will of cause remove it again immediately. But given that that demo page produces pretty much no traffic and graphhopper seems pretty fast, I thought it wouldn't cause any issues. Kai On 07/23/2013 01:22 AM, Peter K wrote: Hi there, yesterday we released the first public version of our fast and Open Source routing engine called GraphHopper. This could be especially interesting for Java developers. You can also try our web application http://graphhopper.com/maps/ with world wide coverage. See the full anouncement here. https://karussell.wordpress.com/2013/07/22/graphhopper-maps-high-performance-and-customizable-routing-in-java/ Let me know if you encounter problems or if you have questions! Regards, Peter. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] API threw unexpected NoMethodError exception
Hey Martin, without giving us an example of your exact problem we can just say: for us this would work... IMO your step by step approach is not sufficient to work properly. You'll need a the driver's final destination and full path. Why? Assume a route A-B-C (where B would have a traffic light) but the fastest or best route would be A-D-E-C (where D has no traffic light). A-B and A-D have the same direction. Now you app would tune the speed (or acceleration) after A regarding B and not E if it does not know the full path. A-D--B | | E--C Also here in my city (Germany) several junctions have a separate lane for turning right. And this lane has no traffic light, but the junction has one! So without knowing the final destination your application would assume there is a traffic light in this direction ... And IMO hitting a server for every turn or road is a waste of resources (battery, bandwith costs etc) Regards, Peter. -- GraphHopper.com Your way is our destination! ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] API threw unexpected NoMethodError exception
Hi Martin, Also here in my city (Germany) several junctions have a separate lane for turning right. And this lane has no traffic light, but the junction has one! you got it. and i can't solve it without a defined junction. All the examples I mean are properly defined (Ie. only if you really cross the junction you'll pass a traffic signal, turning right is mapped as a separate lane without traffic light). So give us the concrete example you mean. Peter. PS: using abbreviations that only google knows doesn't really help to understand your problem ;) (regarding glosa etc) -- GraphHopper.com Your way is our destination! ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] API threw unexpected NoMethodError exception
Hi Martin(s), All the examples I mean are properly defined (Ie. only if you really cross the junction you'll pass a traffic signal, turning right is mapped as a separate lane without traffic light). So give us the concrete example you mean. but of course there are also situations without a separate lane for turning right, e.g. here going from Alberstraße to Stuttgarter Str.: http://www.openstreetmap.org/?lat=48.528626lon=9.077531zoom=18layers=M Of course, there are such situations without separate lanes :) I meant an example of where he has problems with. This particular junction won't be a problem for him IMO the wiki says there is no well established convention how to map traffic signals. Ok, this is an argument but still I would like to see a concrete example which is problematic for you. http://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_signals#How_to_map take this example: http://wiki.openstreetmap.org/wiki/File:Traffic_signals_alternative_mapping.png tell me an algo that solves this question: Still don't get it. Why would this junction be a problem for you? The traffic light is mapped only once on the road: For every combinations of directions you'll get only one traffic signal. See http://www.openstreetmap.org/edit?bbox=3.09915%2C50.95096%2C3.10087%2C50.95144 But probably this all is a big misunderstanding on my side ... Peter. -- GraphHopper.com Your way is our destination! ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] API threw unexpected NoMethodError exception
Martin, routing is not enough Why not? I don't see your problem. Do you have an example? how can i import data partially and consistent? Regarding routing: IMO this is possible when you just import the ways in your current boundary (and all of the involved nodes). one junction = one relation, this is already proposed since many years and You can generate the data you like out of OSM like all routing software is doing these days ... Regards, Peter. routing is not enough martin -- GraphHopper.com Your way is our destination! ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
