[OSM-dev] contribution and usage of maps
Hi Guys, I would like to ask some questions, 1. How can we contribute to update your maps in Australia? 2. How can we use openstreetmap data and maps on our server? 3. For how long can we use those maps will stay for free? I think we can contribute a lot for what you are doing in Australia, Regards Mohamad ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] implemented API for J2SE and J2ME
Well, sounds nice. Where is it? Marcus On Mon, 20 Apr 2009 23:55:59 +0200, Michael Willigens wrote: > Well, > > Concurrency: yes, it can use the calling thread OR it can instantiate > new thread that > will return the result when available to an callback interface. So > anything is thread > save here. > > Memory: Havent tested yet, because i think that parsing small XML > files is also possible > on J2ME. "Could" be improved by implementing a Sax parser in J2ME. I > have thought about > that but i think its kinda overpowered. > > Query Handling: On J2ME it will use the "HTTPConnection" class to get > an InputStream for > the XML parser. On J2SE it will use default URL.openInputStream(). > > API itself: > Some static reachable methods like: > NameFinder.searchAsync(String query, int maxResults, NameFinderCallback c) > NameFinder.search(String query, int maxResults) > will return an array of NameFinderResult Object which basically carry > any data we have on > NameFinder: type, category, name, info, description, nested results... > > Michael ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [Routing] webservice to collect traffic messages
On Mon, 20 Apr 2009 18:46:38 +0200, Doru Julian Bugariu wrote: > marcus.wolsc...@googlemail.com schrieb: > >> I'm thinking about: > > + Use a cool name: "OTM" OpenTrafficMessages > + Version of protocol > >> * required: (enum) event-type >> * required: (string) event-description > > Isn't that redundant to event-type? No. An event-type can only encode a very short list of events like "traffic jam|roadblock|slow|other" but the description can be human readable and contain that it is a "traffic jam due to lost cargo". >> * required: (long) OSM WayID of primary location >> * required: (long) OSM NodeID of primary location > > Why not use dedicated tags and IDs for it? They even may be attached > automatically to existing ways by a bot. Because then only location with these tags can have a traffic message. That would work for TMC-messages but not for others. >> * required: (datatime) expiration date of the event > > Why not starting time and duration? Why would anyone be interested in when the event started? It's there, it will be there when you get there so it's to be used in the metric. >> * optional: (long[]) additional affected nodeIDs >> * optional: (long[]) additional affected wayIDs > > Good idea. > >> * optional: (time) expected delay > > Delay if going through "specified event"? Yes, I like to make it as easy as possible to use the service. It it gets too complicated (like every developer having to figure out a way to calculate how fast you can move in a given traffic jam) noonw will implement clients. >> * optional: (string[]) additionalData > >> Are OSM nodeIDs and wayIDs a usefull reference for other (OSM-) >> applications >> or shall I add required lat + lon + ref/name -attributes? > > Node IDs and Way IDs may change through time. Lon + Lat + Ref/Name may > be hard to code and error-prone. NodeIDs and WayIDs are stable enough for any even that lasts only a few hours anyway but for long lasting events and for clients that did not preserve the entity-IDs or are simply not using the OSM as a map I'll add lat+lon+direction of at least the primary location. That should also eleminate the issue Floris and you pointed out with entity-IDs changing. Marcus ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] implemented API for J2SE and J2ME
On 20 Apr 2009, at 22:59, Grant Slater wrote: > Frederik Ramm wrote: >>> Sounds interesting. >>> Tell us more. Memory Requirements, Concurrency, Query handling, API? >>> etc. >> I think he meant to say he has implemented a client...? > > Damn. > > Namefinder development seems to have taken a break for awhile... > Devs: Got mad coding skillz? Namefinder is ripe for improvement or > replacement. > > There has been talk of holding a virtual or physical meet to > discuss... > > Anyone interested? Improving search for the OSM website could be a topic for: http://wiki.openstreetmap.org/wiki/London_Hack_Weekend Shaun ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] implemented API for J2SE and J2ME
Hi,
Grant Slater wrote:
> Namefinder development seems to have taken a break for awhile...
> Devs: Got mad coding skillz? Namefinder is ripe for improvement or
> replacement.
>
> There has been talk of holding a virtual or physical meet to discuss...
There were, I think, a number of people who made announcements of one
kind or another ("almost completed implementation of new namefinder"
etc) on talk-de, but nothing final has ever come out, I'll inquire about
the status and report.
There was also a recent GSoc proposal by someone I think, someone who
also wanted to do localised search based on current viewport etc.?
Agreed that *good* geocoding is very important, and somewhat of a weak
spot in OSM at the moment...
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33"
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] implemented API for J2SE and J2ME
On Mon, Apr 20, 2009 at 4:59 PM, Grant Slater wrote: > Namefinder development seems to have taken a break for awhile... > Devs: Got mad coding skillz? Namefinder is ripe for improvement or > replacement. > > There has been talk of holding a virtual or physical meet to discuss... > > Anyone interested? I'd love to think about that. Not sure I have time to do much development, but it sure sounds like a fun problem... ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] implemented API for J2SE and J2ME
Frederik Ramm wrote: >> Sounds interesting. >> Tell us more. Memory Requirements, Concurrency, Query handling, API? >> etc. > I think he meant to say he has implemented a client...? Damn. Namefinder development seems to have taken a break for awhile... Devs: Got mad coding skillz? Namefinder is ripe for improvement or replacement. There has been talk of holding a virtual or physical meet to discuss... Anyone interested? / Grant ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] implemented API for J2SE and J2ME
Well, Concurrency: yes, it can use the calling thread OR it can instantiate new thread that will return the result when available to an callback interface. So anything is thread save here. Memory: Havent tested yet, because i think that parsing small XML files is also possible on J2ME. "Could" be improved by implementing a Sax parser in J2ME. I have thought about that but i think its kinda overpowered. Query Handling: On J2ME it will use the "HTTPConnection" class to get an InputStream for the XML parser. On J2SE it will use default URL.openInputStream(). API itself: Some static reachable methods like: NameFinder.searchAsync(String query, int maxResults, NameFinderCallback c) NameFinder.search(String query, int maxResults) will return an array of NameFinderResult Object which basically carry any data we have on NameFinder: type, category, name, info, description, nested results... Michael Quoting Grant Slater : > Sounds interesting. > > Tell us more. Memory Requirements, Concurrency, Query handling, API? etc. > > / Grant > > Michael Willigens wrote: >> Hi osm devlist, >> >> I just wanted to tell you that i implemented a NameFinder API in >> Java because i didnt find anything useful. It will run on both, >> J2SE and ME. Anyone intereseted in this? Shall I contribute it in >> SVN, and whats the email address of David-Earl ? >> >> regards, >> Michael Willigens >> >> ___ >> 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] implemented API for J2SE and J2ME
Hi, Grant Slater wrote: > Sounds interesting. > Tell us more. Memory Requirements, Concurrency, Query handling, API? etc. I think he meant to say he has implemented a client...? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] implemented API for J2SE and J2ME
Sounds interesting. Tell us more. Memory Requirements, Concurrency, Query handling, API? etc. / Grant Michael Willigens wrote: > Hi osm devlist, > > I just wanted to tell you that i implemented a NameFinder API in Java > because i didnt find anything useful. It will run on both, J2SE and > ME. Anyone intereseted in this? Shall I contribute it in SVN, and > whats the email address of David-Earl ? > > regards, > Michael Willigens > > ___ > dev mailing list > dev@openstreetmap.org > http://lists.openstreetmap.org/listinfo/dev > ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] implemented API for J2SE and J2ME
Hi osm devlist, I just wanted to tell you that i implemented a NameFinder API in Java because i didnt find anything useful. It will run on both, J2SE and ME. Anyone intereseted in this? Shall I contribute it in SVN, and whats the email address of David-Earl ? regards, Michael Willigens ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] API 0.6 wiki page
> - In routes.rb there is no api/0.6/relation/:id/:version to retrieve > an old version of a relation but all the neccessary methods are there > (old_relation_controller#version) but there is a type (see attached > diff) I see that someone by the name of "smsm1" has fixed a typo. Unfortunately it is still wrong: This is correct: - render :nothing => true, :status => :internetal_service_error + render :nothing => true, :status => :internal_server_error So "service" needs to be changed to "server", too. And an addition to the routes file if anyone has tested that method. Thanks! ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Routino - a router for OpenStreetMap data
Steve Hosgood writes: > Claudius wrote: >> Am 16.04.2009 18:52, Andrew M. Bishop: >> >>> An online demonstration of the router for the UK is available as well: >>> >>> http://www.gedanken.org.uk/mapping/router/router.html >> The map div of your demo page doesn't show at all in Opera browser. This >> is probably caused by loads of and missing. Use the W3C HTML >> validator to clean up your HTML source: http://validator.w3.org/ >> >> ...and keep your good work. Looks primising. > Yeah - I'll second that. I see the map display is working now, so > obviously the missing tags are fixed. Thanks for the words of encouragement. It wasn't missing tags (they aren't missing, they are optional in HTML 4.01 - the page validated OK) it was a difference of opinion between browsers on how to interpret the HTML/CSS. Apparently an HTML DIV marked with "height: 100%" inside a table row marked as "height: 100%" inside a table marked as "height: 100%" inside an absolutely positioned DIV that fills the window height is only shown as tall as possible in Firefox v3.x and zero height otherwise. I have reverted the HTML/CSS combination to an earlier one that worked. > Useful effects of this router are being able to spot broken connectivity > - especially in things I've not spotted using mkgmap to create Garmin > routable maps for my in-car GPS unit. For instance: things wrong with > the cycleways. As soon as the OSM -> 0.6 API kerfuffle is over, I've got > a few cycleway edits for Swansea! Yes, I have found several of those while developing it. Also roundabouts not tagged as such (it was routing the wrong way round). I had thought about using it to find roads that are not connected to the highway network. Start somewhere that obviously is connected and try routing to one node on each other road way. I don't know how you would interpret the data though. It also wouldn't find breaks that can be routed round. > May I offer a couple of comments please: > 1) The positioning of the 'start' and 'end' markers for the route are a > bit over-critical. The slippy map provided doesn't let you zoom in > enough to place them accurately enough. Either please add a further > layer of zoom to the zoom-tool, or increase the tolerance for searching > for a road near the 'start' or 'end' markers. Currently it finds the closest highway node of any type. I have been thinking about limiting it to finding only nodes that are connected to highway types that you have selected to use. This should solve your problem. > 2) Would be nice to mark a road type as "avoid if possible". For > instance, when finding a bicycle route you might like to mark primary > roads in that way. I obtained a similar result by setting the speed > limit for a primary as 5kph, then selecting "find fastest" but of course > the estimated arrival time would be skewed by doing that. I'd might > expect to do 20kph on a bike on a primary if I was on such a road, but > would rather not be there in the first place. Sometimes, there's just no > avoiding riding the bike on a primary - or even a trunk. This is already a work in progress - replacing the yes/no selection with a percentage preference. > Other than that - great work, neat GUI, interesting results. > Keep it up, and thanks for what you've done so far. -- Andrew. -- Andrew M. Bishop a...@gedanken.demon.co.uk ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [Routing] webservice to collect traffic messages
marcus.wolsc...@googlemail.com schrieb: > I'm thinking about: + Use a cool name: "OTM" OpenTrafficMessages + Version of protocol > * required: (enum) event-type > * required: (string) event-description Isn't that redundant to event-type? > * required: (long) OSM WayID of primary location > * required: (long) OSM NodeID of primary location Why not use dedicated tags and IDs for it? They even may be attached automatically to existing ways by a bot. > * required: (datatime) expiration date of the event Why not starting time and duration? > * optional: (long[]) additional affected nodeIDs > * optional: (long[]) additional affected wayIDs Good idea. > * optional: (time) expected delay Delay if going through "specified event"? > * optional: (string[]) additionalData > Are OSM nodeIDs and wayIDs a usefull reference for other (OSM-) > applications > or shall I add required lat + lon + ref/name -attributes? Node IDs and Way IDs may change through time. Lon + Lat + Ref/Name may be hard to code and error-prone. Julian signature.asc Description: OpenPGP digital signature ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] webservice to collect traffic messages
maybe also include a (optional) last modified date for the id's so you can check if they have been changed? road construction can take a long time. when osm-er changes the road that might be the new situation. greetings, floris > > Hello, > > I'd like to experiment with Google AppEngine for a bit and > set up a hosted service to collect traffic messages > (traffic jams, road obstructions, constructions sites, slow > moving traffic,...) > > What could be a good data-format for such information, so that > it is usefull to more then just my own navigator? > I'm thinking about: > * required: (enum) event-type > * required: (string) event-description > * required: (long) OSM WayID of primary location > * required: (long) OSM NodeID of primary location > * required: (datatime) expiration date of the event > * optional: (long[]) additional affected nodeIDs > * optional: (long[]) additional affected wayIDs > * optional: (time) expected delay > * optional: (string[]) additionalData > > Are OSM nodeIDs and wayIDs a usefull reference for other (OSM-) > applications > or shall I add required lat + lon + ref/name -attributes? > > Marcus > > ___ > 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] API 0.6 wiki page
> - In routes.rb there is no api/0.6/relation/:id/:version to retrieve > an old version of a relation but all the neccessary methods are there > (old_relation_controller#version) but there is a type (see attached > diff) type -> typo > - For "ways for node" and "relations for element" there is no error > if the given element does not exist - I've attached diffs that I've > coded without trying. All other methods return a 404 if a element does > not exist Not without trying ;-) But the code is completely untested. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] API 0.6 wiki page
I finished most of the methods now. Some may be incomplete but...well..work in progress ;-) A few comments though: - The changeset methods allow multiple XML elements and the resulting changeset will be a combination of them all. The node/way/element methods allow multiple elements, too but they only use the very first - Is a expanded bounding box (via expand_bbox) useful in any way in regard to performance? There were hints about that on the page and in the code - The implementation of the 'time' parameter for the changesets query differs from what was documented on the page - Doc: One-sided to query changesets where the start time is after the given time. Implemented: One-sided to query changesets where the _close_ time is after the given time. - Doc: Bounded (?time=T1,T2) to query where the start time is between the given times. Implemented: Find changesets that were closed after T1 and created before T2 - The "changeset summary" is - in my opinion - not very helpful and it is erroneus but I didn't want to just delete it right now - I haven't yet looked to close at the delete methods but if I remember correctly one needs to send a valid element although only version and changeset are used, correct? (lat/lon for nodes are required) - In routes.rb there is no api/0.6/relation/:id/:version to retrieve an old version of a relation but all the neccessary methods are there (old_relation_controller#version) but there is a type (see attached diff) - For "ways for node" and "relations for element" there is no error if the given element does not exist - I've attached diffs that I've coded without trying. All other methods return a 404 if a element does not exist - When creating an object (and I'm sure there are many more occasions) while missing a changeset id the error message that is returned is different for nodes, ways and relations That's all I could find so far. I didn't change the error messages as I do not now if anyone or anything depends on them but I would check the code if I get a green light for it ;-) Lars old_relation_controller.patch Description: Binary data misc.patch Description: Binary data ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] webservice to collect traffic messages
On Mon, 20 Apr 2009 07:56:13 -0400, Greg Troxel wrote: > writes: > >> I'd like to experiment with Google AppEngine for a bit and >> set up a hosted service to collect traffic messages >> (traffic jams, road obstructions, constructions sites, slow >> moving traffic,...) > > I'm not sure how you're intending to use this, but I'm guessing peer ... Actually it's just going to be a proof of concept. If the format as well as my atempt to get input from the other developers of the other navigators work out I am thinking about having some fun with car2car. For that traffic messages in a general format would be a good starting point and then there are lots of fun things you can do with map-updates and communication while driving in a convoy. At the moment I get lots of traffic messages from TMC but I don't want to hardcode a specific source of such information. Keep it open for others with good ideas. > Have you looked at the format specs for TMC: > > http://en.wikipedia.org/wiki/Traffic_Message_Channel > > It's not the least bit clear that it's the right thing, but probably > worth glancing at. Well, I am programming on the TMC LocationCodeList-import for Germany (Roads work, Segments are difficult, Points get scary), did the TMC-implementation in Traveling Salesman and have the ISO-documents on it next to me. ..too late, I already glanced. ;) >> What could be a good data-format for such information, so that >> it is usefull to more then just my own navigator? >> I'm thinking about: >> * required: (enum) event-type >> * required: (string) event-description >> * required: (long) OSM WayID of primary location >> * required: (long) OSM NodeID of primary location > > Not sure what you mean by long, but protocols should only use > fixed-width types, so perhaps uint32_t, or perhaps uint64_t to avoid > having to change the protocol when there are more than 4G nodes. Or > perhaps this is xml so it's just a number. long=signed 64bit integer. The datatype osmosis uses for IDs and thus the one I inherited for all my code. >> * required: (datatime) expiration date of the event > > I don't follow this - I would expect a time of report, and perhaps an > expected time remaining. time of report + expected duration = expiration time. >> * optional: (long[]) additional affected nodeIDs >> * optional: (long[]) additional affected wayIDs > >> * optional: (time) expected delay > > Presumably this is the number of seconds that travel would take minus > the number it would take under normal time? I was thinking about milliseconds as that is the natural unit of time but yes. In TMC I sometimes get this in minutes, sometimes I get a length of a traffic jam and can aproximate this. >> * optional: (string[]) additionalData > > for humans? For future extensions. Never design a protocoll without either a version number or fields reserved for extending it. >> Are OSM nodeIDs and wayIDs a usefull reference for other (OSM-) >> applications >> or shall I add required lat + lon + ref/name -attributes? > > With OSM ids, one can only generate and use data if one has OSM data > locally, and then only if it's the same version - what if there was an > edit to add/remove ways that didn't really change the map massively > semantically, but changed way ids? I find it very hard to map things line "road-name"+"lat"+"lon" to a way efficiently and correctly. That's why I am asking for better options. > This data could be useful to display without the detailed database. > > It would be nice to have this data be useful over long time scales, > looking at the frequency of (reported) trouble. So using way ids as the > primary key seems like it could be trouble. > > I would expect that routing applications have to figure out from > position where one is anyway, so reporting by lat/lon makes sense. > Except in very messy areas with lots of stacked ramps. Take a simple dual-carriageway or the usual case that a traffic jam is reported to start at a motorway-crossing. There are lots of ways. > So perhaps lat/lon, and an optional way id for disambiguation, but which > can be ignored if it doesn't make sense. Lat+Lon+direction of moving traffic could be more stable if the nodes get moved around. Marcus ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] webservice to collect traffic messages
writes: > I'd like to experiment with Google AppEngine for a bit and > set up a hosted service to collect traffic messages > (traffic jams, road obstructions, constructions sites, slow > moving traffic,...) I'm not sure how you're intending to use this, but I'm guessing peer reports of issues from people running open source in-car navigation, perhaps to the point that driving below expected speeds might trigger automatic reports. I would expect you are thinking cellphone data service, but car-car 802.11 with Disruption Tolerant Networking is also very interesting. Perhaps you could describe your goals and use cases. I realize only some of the people here fall into the paranoid category, but such reports,sent more than very occasionally, and perhaps even at all will cause the paranoid to worry. (Of course we keep our phones off too :-). So it would be nice to give some thought to the privacy issues of anonymous reports together with avoiding false reports. This is definitely hard. Given the privacy worries, google is a bit scary - not sure what the policy is on use of hosted apps data for targeting ads... Have you looked at the format specs for TMC: http://en.wikipedia.org/wiki/Traffic_Message_Channel It's not the least bit clear that it's the right thing, but probably worth glancing at. > What could be a good data-format for such information, so that > it is usefull to more then just my own navigator? > I'm thinking about: > * required: (enum) event-type > * required: (string) event-description > * required: (long) OSM WayID of primary location > * required: (long) OSM NodeID of primary location Not sure what you mean by long, but protocols should only use fixed-width types, so perhaps uint32_t, or perhaps uint64_t to avoid having to change the protocol when there are more than 4G nodes. Or perhaps this is xml so it's just a number. > * required: (datatime) expiration date of the event I don't follow this - I would expect a time of report, and perhaps an expected time remaining. > * optional: (long[]) additional affected nodeIDs > * optional: (long[]) additional affected wayIDs > * optional: (time) expected delay Presumably this is the number of seconds that travel would take minus the number it would take under normal time? > * optional: (string[]) additionalData for humans? > Are OSM nodeIDs and wayIDs a usefull reference for other (OSM-) > applications > or shall I add required lat + lon + ref/name -attributes? With OSM ids, one can only generate and use data if one has OSM data locally, and then only if it's the same version - what if there was an edit to add/remove ways that didn't really change the map massively semantically, but changed way ids? This data could be useful to display without the detailed database. It would be nice to have this data be useful over long time scales, looking at the frequency of (reported) trouble. So using way ids as the primary key seems like it could be trouble. I would expect that routing applications have to figure out from position where one is anyway, so reporting by lat/lon makes sense. Except in very messy areas with lots of stacked ramps. So perhaps lat/lon, and an optional way id for disambiguation, but which can be ignored if it doesn't make sense. pgptTpNlEQ6rq.pgp Description: PGP signature ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Routino - a router for OpenStreetMap data
Claudius wrote: > Am 16.04.2009 18:52, Andrew M. Bishop: > >> An online demonstration of the router for the UK is available as well: >> >> http://www.gedanken.org.uk/mapping/router/router.html >> > > The map div of your demo page doesn't show at all in Opera browser. This > is probably caused by loads of and missing. Use the W3C HTML > validator to clean up your HTML source: http://validator.w3.org/ > > ...and keep your good work. Looks primising. > Yeah - I'll second that. I see the map display is working now, so obviously the missing tags are fixed. Useful effects of this router are being able to spot broken connectivity - especially in things I've not spotted using mkgmap to create Garmin routable maps for my in-car GPS unit. For instance: things wrong with the cycleways. As soon as the OSM -> 0.6 API kerfuffle is over, I've got a few cycleway edits for Swansea! May I offer a couple of comments please: 1) The positioning of the 'start' and 'end' markers for the route are a bit over-critical. The slippy map provided doesn't let you zoom in enough to place them accurately enough. Either please add a further layer of zoom to the zoom-tool, or increase the tolerance for searching for a road near the 'start' or 'end' markers. 2) Would be nice to mark a road type as "avoid if possible". For instance, when finding a bicycle route you might like to mark primary roads in that way. I obtained a similar result by setting the speed limit for a primary as 5kph, then selecting "find fastest" but of course the estimated arrival time would be skewed by doing that. I'd might expect to do 20kph on a bike on a primary if I was on such a road, but would rather not be there in the first place. Sometimes, there's just no avoiding riding the bike on a primary - or even a trunk. Other than that - great work, neat GUI, interesting results. Keep it up, and thanks for what you've done so far. Steve ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] webservice to collect traffic messages
Hello, I'd like to experiment with Google AppEngine for a bit and set up a hosted service to collect traffic messages (traffic jams, road obstructions, constructions sites, slow moving traffic,...) What could be a good data-format for such information, so that it is usefull to more then just my own navigator? I'm thinking about: * required: (enum) event-type * required: (string) event-description * required: (long) OSM WayID of primary location * required: (long) OSM NodeID of primary location * required: (datatime) expiration date of the event * optional: (long[]) additional affected nodeIDs * optional: (long[]) additional affected wayIDs * optional: (time) expected delay * optional: (string[]) additionalData Are OSM nodeIDs and wayIDs a usefull reference for other (OSM-) applications or shall I add required lat + lon + ref/name -attributes? Marcus ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] API 0.6 wiki page
Hi, Lars Francke wrote: > I documented what I found in the code. This sometimes varied from the > documentation on the wiki page but as the API will be live in a few > hours I think this is the way to go. The wiki page can be updated when > the code is updated. You could probably save some work if you just take the rather well documented 0.5 API page and make the necessary changes. It's not that we have a complete rewrite ;-) Bye Frederik ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
