Re: [talk-ph] routing problems in Pampanga area
Great work guys! This seems fixed. Although I did found other errors will help fix-up later. On Wed, Apr 8, 2009 at 11:10 AM, maning sambale emmanuel.samb...@gmail.com wrote: link: http://www.yournavigation.org/?flat=15.019941flon=120.66741tlat=15.251051tlon=120.563469v=motorcarfast=0layer=mapnik -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] laguna lake dried-up!
Laguna lake dried up again (is this a seasonal thing?) http://www.openstreetmap.org/?lat=14.4lon=121.212zoom=11layers=B000FTF It looks better in osmarender though. Anyway, the area seems to have multipolygon relations for water. I fixed a few duplicate nodes but I'm not sure if that caused the rendering problem. On Fri, Jan 9, 2009 at 8:27 PM, Ian Haylock haylo...@yahoo.co.uk wrote: But, at least the Osmarender is now correct, no more flooding Swings and roundabouts... Cheers, Ian --- On Thu, 8/1/09, maning sambale emmanuel.samb...@gmail.com wrote: From: maning sambale emmanuel.samb...@gmail.com Subject: [talk-ph] laguna lake dried-up! To: osm-ph talk-ph@openstreetmap.org Date: Thursday, 8 January, 2009, 12:33 PM http://www.openstreetmap.org/?lat=14.336lon=121.247zoom=11layers=B000FTF -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [OSM-talk-be] naming tramlines
On Thursday 23 April 2009, Maarten Deen wrote: l...@xs4all.nl wrote: ah yes. Once again didn't think about the info that's included - but invisible - already. But which would need some work to be available to the renderer. osm2pgsql should take the info from the relations and 'flatten' it into the physical tramline data. For bonus points: preserve an existing name, and append the tramline numbers. For extra bonus points: keep the tramline numbers ordered. What a renderer should do is take a key from the way and the relation and concatenate them using a separator character. Both the key name and the separator character should be specified in the rendering rules. And if a namerendering like this is required of course. And if and how they should be sorted. But for as long as such a rendering is not made, I would not object to putting the linenumbers in the name tag of the way. It is very useful information, and can be weeded out quite easily if a future render can use the relations. -1. Improve the renderers, period. And if some rendering doesn't want to show the tram numbers, then we shouldn't force them by using tags that weren't meant for it. We're also not adding the bus numbers on street names or train numbers on railway tracks just because they might be useful, right? Ben ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] naming tramlines
That's exactly what was my first posting about. I just noticed the result on the Poznan map and it looked nice and usefull. Though I 'know' that relations exist and what they are used for, I am quite unfamiliar with them so that was the reason why I didn't think about those in the first place. But they are quite new, let's give the people that work on the rendering the time to implement it, and save us the effort of putting in a lot of redundant information in the tags. Luc / Speedy On Thu, 2009-04-23 at 15:03 +0200, Martijn van Exel wrote: -1. This would indeed be satisfying the wish for nice line labeling on tram lines in the short term. However, implementing this one-time might encourage others to just tag tram lines in this fashion and not even bother about the relations. You know how these things go, as soon as you start doing this at any serious scale, people will adapt it as best practice and we will end up doing renderer-driven tagging, to which I am quite vehemently opposed. Cross posting to talk. martijn van exel -+- mve...@gmail.com -+- http://www.schaaltreinen.nl/ On Thu, Apr 23, 2009 at 13:54, Maarten Deen md...@xs4all.nl wrote: l...@xs4all.nl wrote: ah yes. Once again didn't think about the info that's included - but invisible - already. But which would need some work to be available to the renderer. osm2pgsql should take the info from the relations and 'flatten' it into the physical tramline data. For bonus points: preserve an existing name, and append the tramline numbers. For extra bonus points: keep the tramline numbers ordered. What a renderer should do is take a key from the way and the relation and concatenate them using a separator character. Both the key name and the separator character should be specified in the rendering rules. And if a namerendering like this is required of course. And if and how they should be sorted. But for as long as such a rendering is not made, I would not object to putting the linenumbers in the name tag of the way. It is very useful information, and can be weeded out quite easily if a future render can use the relations. Maarten ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-legal-talk] Substantial meaning
On Apr 23, 2009, at 2:42 PM, SteveC wrote: Has there been any discussion on what people here feel 'substantial' means in the context of the definitions of the ODbL? It's definitely substantial if somebody extracts something matching a single criteria, e.g. an entire state, an entire country, an entire theme (e.g. everything tagged with cycleway). -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - Twitter: Russ_OSM - http://openstreetmap.org/user/RussNelson ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Substantial meaning
Hi, Iván Sánchez Ortega wrote: If the extraction needs an automated tool, then it is substantial. Uh. This means that even the answer to the question what is the name of the street at lat=12.345 lon=45.789 would be a substantial extract because you cannot possibly peer through the XML to find that out (imagine the time it needs to determine the nodes in the vicinity, then find the ways using these nodes and compute which of them comes near that location). Then again, Filtering out all amenity=pub in a small area is not substantial (e.g. all pubs in a 100m x 100m bbox - again, just peer through the XML with *any* text editor and Ctrl+F) your raw XML processing capabilites seem to vastly exceed mine ;-) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Substantial meaning
El Jueves, 23 de Abril de 2009, Frederik Ramm escribió: Iván Sánchez Ortega wrote: If the extraction needs an automated tool, then it is substantial. Uh. This means that even the answer to the question what is the name of the street at lat=12.345 lon=45.789 would be a substantial extract because you cannot possibly peer through the XML[...] Nope. To do that, you'll load up your web browser (or your favourite virtual globe), center on 12.345,45.678 and look around. Now, a web browser + openlayers (or Marble, or whatever) is neither a specific nor specialized tool to methodically looking for street names near a given pair of coordinates. It's a friggin' map. Now, if you load that data as XML into a GIS, and use some geo-processing to define a buffer and then intersect ways with a highway=tag and then extract the name= and then output a pretty table, then you're using specialized software. My point is: if a task is tedious enough so that you have to use a GIS, or code your own solution, or load the data into a DB to use some SQL magic, then the extraction is substantial. If you can use tools *not* designed for manipulating databases (e.g. a web browser with openlayers to look for a street name, a text editor for the XML for search an amenity=pub), then the extraction is not substantial. I believe there is a tipping point in the complexity of a problem in which you have to look into specialized software (GIS, CAD, DB admin, custom scripting stuff) if you want to solve the problem before dying of old age. IMHO, that tipping point is the frontier between substantial and non-substantial. Filtering out all amenity=pub in a small area is not substantial (e.g. all pubs in a 100m x 100m bbox - again, just peer through the XML with *any* text editor and Ctrl+F) your raw XML processing capabilites seem to vastly exceed mine ;-) ...there's way too much information to decode the Matrix. You get used to it, though. Your brain does the translating. I don't even see the code. All I see is blonde, brunette, redhead. :-D -- -- Iván Sánchez Ortega i...@sanchezortega.es MSN:i_eat_s_p_a_m_for_breakf...@hotmail.com Jabber:ivansanc...@jabber.org ; ivansanc...@kdetalk.net signature.asc Description: This is a digitally signed message part. ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] Wrong scale in slippy map
Looking at the area where I live, http://www.openstreetmap.org/?lat=58.407lon=15.600zoom=18layers=B000FTF these buildings are 11 metres wide and not 22 metres as the scale indicates. The difference is explained by the latitude 58.4 degrees and cosine(60°) = 0.5. Maybe one year back, I reported exactly this bug in JOSM and it was fixed. Now I find it in the slippy map. How long has it been there? Is it an OpenStreetMap bug or a OpenLayers bug? The metre was once defined as one ten-millionth of the distance from the equator to the north pole. Each latitude degree (of which there are 90) is thus 111 km long, everywhere. At the equator, each longitude degree is also 111 km, but at the latitude of 60° (Oslo-Stockholm-Helsinki-St. Petersburg), each longitude degree is only 56 km. At each zoom level of the slippy map, the longitudes (meridians) run vertical at a constant pixel width, meaning that the scale (metres on ground to pixels on screen) changes as you pan north or south. The scale is different at the top and bottom of the screen, very much so at the low zoom numbers, but insignificantly at the higher (deeper) zoom levels. -- Lars Aronsson (l...@aronsson.se) Aronsson Datateknik - http://aronsson.se == Hello. I have changed my mind lately regarding this issue. I think there are two ways to approach this, and both are legitimate: - Strictly: every coordinate system has has pros and cons when drawing a world map. If you have a map in EPSG:4326, Greenland is awfully stretched, etc, but that's the way it is using that ref. system. If you use the British national grid for all of Europe, many countries will look ridiculous, but, whether we like it or not, those are the coordinates of those countries in that projection. That is happening in Scandinavia with Spherical Mercator: Sweden is ridiculously large, but sorry, that's the way it is using that projection, so the scale bar is right. The problem is that the projection is not good for that part of the world. - Using common sense: As you say, the top and bottom of the screen have about the same scale if you zoom in a bit, so it is possible to forget about the coordinates provided by the projection and create a locally sensible scale bar. I have seen the first option used on OSM's front page and the second option in Cloudmade's website. Regards, Juan Lucas ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Africa Road data import
Hi Robert, Looks good. Where did the UN agencies get their data from? Did all this data originate from within the UN agencies through GPS traces or did they source it from somewhere else? Regards Neil --- On Thu, 23/4/09, Robert Soden robert.so...@gmail.com wrote: From: Robert Soden robert.so...@gmail.com Subject: [OSM-talk] Africa Road data import To: talk@openstreetmap.org Received: Thursday, 23 April, 2009, 4:54 AM Hello, I wrote a little while back that we would be working on some data imports for Africa. In short, we received permission from 2 different UN data repo's to contribute their base road, river, rail, and admin boundary data to OSM. So far, we have cleaned and imported 6 countries worth of road layers. Next up is to do some final QA, once we can see the data in Potlach, then onto the other layers for each of the 6 countries. And there are still 5 more countries available to us to work on. I wrote a blog-post about the progess thus far here: http://is.gd/ tTb4 All seemed to go well with the import under the new API, though we had a bit of trouble with DRC (it's a huge file). We've received several emails from folks wanting to help us in this process. Now that we (think) we've got our feet under us, we hope to work with them as we process the remaining data. Cheers, Robert Soden Development Seed http://developmentseed.org ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk Enjoy a better web experience. Upgrade to the new Internet Explorer 8 optimised for Yahoo!7. Get it now.___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] mapnik weekly rendering after API 0.6
Is the weekly Mapnik rendering process still running after the upgrade to API 0.6? If so, which day is it scheduled for? It will still occurs on Wednesdays. I have started off the import this evening so it should begin rendering the latest changes tomorrow. so it's normally on a cron schedule, but this time it was started manually? Out of interest, since Mapnik seems to process the entire world quite quickly, why is it not invoked when a tile is dirty, like osmarender? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wrong scale in slippy map
Juan Lucas Dominguez Rubio jldominguez at prodevelop.es writes: That is happening in Scandinavia with Spherical Mercator: Sweden is ridiculously large, but sorry, that's the way it is using that projection, so the scale bar is right. The problem is that the projection is not good for that part of the worl. - Using common sense: As you say, the top and bottom of the screen have about the same scale if you zoom in a bit, so it is possible to forget about the coordinates provided by the projection and create a locally sensible scale bar.I have seen the first option used on OSM's front page and the second option in Cloudmade's website.Regards,Juan Lucas Hi, I believe also that the scale bar is not right. Distorsion is one thing, it makes Sweden (and Finland) to look visually ridiculous on the map, but it does not mean that these countries are twice as large in the real life. Scale bar values, if presented in meters/feet, should be adjusted according to latitude. Even then it cannot be correct for the whole map, but showing the corrrect scale for the middle latitude of a would perhaps be the best compromise. Of course if scale were presented in degrees then it would be correct universally, but that would not be very useful for average users. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Africa Road data import
Hello Robert, thks for your contribution. While waiting for OSM to render your tiles, you can take a look to this one that has realtime rendering and compare it with Google Maps and Yahoo Maps layers to check ur data. http://sautter.com/map/ Best Regards. On Wed, Apr 22, 2009 at 8:54 PM, Robert Soden robert.so...@gmail.comwrote: Hello, I wrote a little while back that we would be working on some data imports for Africa. In short, we received permission from 2 different UN data repo's to contribute their base road, river, rail, and admin boundary data to OSM. So far, we have cleaned and imported 6 countries worth of road layers. Next up is to do some final QA, once we can see the data in Potlach, then onto the other layers for each of the 6 countries. And there are still 5 more countries available to us to work on. I wrote a blog-post about the progess thus far here: http://is.gd/ tTb4 All seemed to go well with the import under the new API, though we had a bit of trouble with DRC (it's a huge file). We've received several emails from folks wanting to help us in this process. Now that we (think) we've got our feet under us, we hope to work with them as we process the remaining data. Cheers, Robert Soden Development Seed http://developmentseed.org ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wrong scale in slippy map
Lars Aronsson schrieb: Looking at the area where I live, http://www.openstreetmap.org/?lat=58.407lon=15.600zoom=18layers=B000FTF these buildings are 11 metres wide and not 22 metres as the scale indicates. The difference is explained by the latitude 58.4 degrees and cosine(60°) = 0.5. Maybe one year back, I reported exactly this bug in JOSM and it was fixed. Now I find it in the slippy map. How long has it been there? Is it an OpenStreetMap bug or a OpenLayers bug? This didn't work correctly from the start. It's an OpenLayers bug, since OpenLayers has no dynamic scale object IIRC. -- Dirk-Lüder Deelkar Kreie Bremen - 53.0952°N 8.8652°E signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wrong scale in slippy map
Hi, Lars Aronsson wrote: Looking at the area where I live, http://www.openstreetmap.org/?lat=58.407lon=15.600zoom=18layers=B000FTF these buildings are 11 metres wide and not 22 metres as the scale indicates. The difference is explained by the latitude 58.4 degrees and cosine(60°) = 0.5. Give us a break and move to the equator. Everything is fine there. Bye Frederi ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Placeopedia replacement
All I used to use a site called placeopedia that showed a map with Wikipedia articles located on it. http://www.placeopedia.com/ Quite useful if you're planning a route and you want to see interesting sights slong the way Is anyone aware of a similar openstreetmap replacment? Cheers Mike ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wrong scale in slippy map
On Thu, Apr 23, 2009 at 08:23:16AM +, Jukka Rahkonen wrote: not mean that these countries are twice as large in the real life. Scale bar values, if presented in meters/feet, should be adjusted according to latitude. Even then it cannot be correct for the whole map, but showing the corrrect scale for the middle latitude of a would perhaps be the best compromise. If we could get two scales, at the top and at the bottom of the map, then it would give us even more correct information. But one scale will be enough, when correct. Incorrect meter/feet scale is quite useless and probably better would to not use such scale at all. Greets, Jacek ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Placeopedia replacement
http://gpsies.com/ is not opensource and it defaults to google maps, but it has openstreetmap support, as well as many other cool features. On Thu, Apr 23, 2009 at 11:04 AM, Mike Ryan mike.r...@redmar.com wrote: All I used to use a site called placeopedia that showed a map with Wikipedia articles located on it. http://www.placeopedia.com/ Quite useful if you're planning a route and you want to see interesting sights slong the way Is anyone aware of a similar openstreetmap replacment? Cheers Mike ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Delay before the data is visible?
On Tue, 21 Apr 2009, Jonathan Bennett wrote: It could be that you get no warning when the upload fails under certain circumstances. Hasn't happened to me on the latest SVN build, though. I noticed the exact opposite to this on Tuesday - JOSM thought the upload had failed, the OSM servers thought it succeeded. The result was that the next attempt the upload successfully re-uploaded the same data. - Steve xmpp:st...@nexusuk.org sip:st...@nexusuk.org http://www.nexusuk.org/ Servatis a periculum, servatis a maleficum - Whisper, Evanescence ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] mapnik weekly rendering after API 0.6
El Jueves, 23 de Abril de 2009, Joe Richards escribió: Out of interest, since Mapnik seems to process the entire world quite quickly, why is it not invoked when a tile is dirty, like osmarender? It is. Either a tile is requested in real-time (if it doesn't exist) or is queued if the tile is old (via render_old). mod_tile is an amazing piece of software indeed. -- -- Iván Sánchez Ortega i...@sanchezortega.es I want to share something with you: The three little sentences that will get you through life. Number 1: Cover for me. Number 2: Oh, good idea, Boss! Number 3: It was like that when I got here. -- Homer Simpson signature.asc Description: This is a digitally signed message part. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Delay before the data is visible?
On Tue, 21 Apr 2009, Shaun McDonald wrote: The renderers are delayed until the minutely diff are working again. There are some bugs there that need to be resolved first. Then there will be a delay of a few hours/days once the diffs come back up. Some curiosities/observations: 1. Is OSM now using the tile expiry code I implemented in osm2pgsql to work out what to re-render, or is it using something different? 2. I noticed the minutely deltas are now delayed by an hour (used to be about 5 minutes). Is this down to server load? If so, why are the servers suddenly so much busier than before the API change (there don't seem to be that many uploads happenning and I wouldn't have thought there would be a big increase in downloads since the API change). 3. The deltas are much smaller than they used to be and there are long periods where they are completely empty. A look at the recent changes page seems to show that there really are long periods when no one is committing any data. Is this down to people actually not trying to upload anything or is the API undergoing periods of breakage so that people can't upload anything? - Steve xmpp:st...@nexusuk.org sip:st...@nexusuk.org http://www.nexusuk.org/ Servatis a periculum, servatis a maleficum - Whisper, Evanescence ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wrong scale in slippy map
2009/4/23 Jacek Konieczny jaj...@jajcus.net: On Thu, Apr 23, 2009 at 08:23:16AM +, Jukka Rahkonen wrote: not mean that these countries are twice as large in the real life. Scale bar values, if presented in meters/feet, should be adjusted according to latitude. Even then it cannot be correct for the whole map, but showing the corrrect scale for the middle latitude of a would perhaps be the best compromise. If we could get two scales, at the top and at the bottom of the map, then it would give us even more correct information. But one scale will be enough, when correct. Incorrect meter/feet scale is quite useless and probably better would to not use such scale at all. Call me stupid but are we not going to need a different scale bar for North - South as well. Its like putting a Standard 1024x768 display on a wide screen monitor everything gets stretched. You could have more tiles at the equator than at the poles. Dreaming that the world can be stretched to fit on a square is always going have a problem somewhere. Ideally you want a map so where a fixed distance is a fixed number of pixels on screen and angles are correct at least for the bit of the world you are currently looking at This should be doable at least for higher zoom levels, How you do this I'm not 100% sure. Regards Peter. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Placeopedia replacement
Thanks Nic. That seems to be more for tracks. In it's simplest form, I'm just looking for a map with Points of Interest highlighted on it, ie, tourist attractions and things to see and do 2009/4/23 Nic Roets nro...@gmail.com: http://gpsies.com/ is not opensource and it defaults to google maps, but it has openstreetmap support, as well as many other cool features. On Thu, Apr 23, 2009 at 11:04 AM, Mike Ryan mike.r...@redmar.com wrote: All I used to use a site called placeopedia that showed a map with Wikipedia articles located on it. http://www.placeopedia.com/ Quite useful if you're planning a route and you want to see interesting sights slong the way Is anyone aware of a similar openstreetmap replacment? Cheers Mike ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wrong scale in slippy map
On Thu, Apr 23, 2009 at 11:45 AM, Peter Childs pchi...@bcs.org wrote: 2009/4/23 Jacek Konieczny jaj...@jajcus.net: On Thu, Apr 23, 2009 at 08:23:16AM +, Jukka Rahkonen wrote: not mean that these countries are twice as large in the real life. Scale bar values, if presented in meters/feet, should be adjusted according to latitude. Even then it cannot be correct for the whole map, but showing the corrrect scale for the middle latitude of a would perhaps be the best compromise. If we could get two scales, at the top and at the bottom of the map, then it would give us even more correct information. But one scale will be enough, when correct. Incorrect meter/feet scale is quite useless and probably better would to not use such scale at all. Call me stupid but are we not going to need a different scale bar for North - South as well. Its like putting a Standard 1024x768 display on a wide screen monitor everything gets stretched. You could have more tiles at the equator than at the poles. Dreaming that the world can be stretched to fit on a square is always going have a problem somewhere. Ideally you want a map so where a fixed distance is a fixed number of pixels on screen and angles are correct at least for the bit of the world you are currently looking at This should be doable at least for higher zoom levels, How you do this I'm not 100% sure. If you want it done right, then your scale bar has detatchable end points. You drag one end of the scale bar to one end of the feature, the other to the other, and then the scale bar warps itself into a great-circle curve and tells you how long it is. Everything else is a compromise :-) Cheers, Andy PS altering the scale bar whilst panning is possible, it's something we've done in our Web Maps Lite javascript API here at CloudMade. See http://maps.cloudmade.com for an example. But it's still an approximation, especially where the distances are significantly different at different parts of the viewport (it can only give one scale at a time!) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wrong scale in slippy map
If you want it done right, then your scale bar has detatchable end points. You drag one end of the scale bar to one end of the feature, the other to the other, and then the scale bar warps itself into a great-circle curve and tells you how long it is. Which would actually be an incredibly cool feature to have, it is essentially a measuring device between two points on the map - any javascript experts out there willing to code this up? Cheers, Donald ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wrong scale in slippy map
If you want it done right, then your scale bar has detatchable end points. You drag one end of the scale bar to one end of the feature, the other to the other, and then the scale bar warps itself into a great-circle curve and tells you how long it is. Which would actually be an incredibly cool feature to have, it is essentially a measuring device between two points on the map - any javascript experts out there willing to code this up? Measuring point to point on a map is already in openlayers: http://openlayers.org/dev/examples/measure.html ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Delay before the data is visible?
2009/4/22 Ed Loach e...@loach.me.uk How large is the current delay before uploaded data became visible? My question is slightly different. I uploaded two changesets successfully earlier from JOSM (the third took over an hour so I clicked Abort and ended up losing my edits, so lucky there weren't too many. I'll try again when things calm down a bit). http://www.openstreetmap.org/user/EdLoach/edits FYI, I had a problem uploading earlier due to the API not responding to the create changeset request, I also hit cancel, though the subsequent abort didn't complete, so closed the upload window, subsequent upload attempts seeming didn't result in JOSM actually trying again, at this point I was able to save the changes and have since reopened and uploaded them when the API has become available again... No edits lost... Using josm 1529... d ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [OSM-talk-be] naming tramlines
-1. This would indeed be satisfying the wish for nice line labeling on tram lines in the short term. However, implementing this one-time might encourage others to just tag tram lines in this fashion and not even bother about the relations. You know how these things go, as soon as you start doing this at any serious scale, people will adapt it as best practice and we will end up doing renderer-driven tagging, to which I am quite vehemently opposed. Cross posting to talk. martijn van exel -+- mve...@gmail.com -+- http://www.schaaltreinen.nl/ On Thu, Apr 23, 2009 at 13:54, Maarten Deen md...@xs4all.nl wrote: l...@xs4all.nl wrote: ah yes. Once again didn't think about the info that's included - but invisible - already. But which would need some work to be available to the renderer. osm2pgsql should take the info from the relations and 'flatten' it into the physical tramline data. For bonus points: preserve an existing name, and append the tramline numbers. For extra bonus points: keep the tramline numbers ordered. What a renderer should do is take a key from the way and the relation and concatenate them using a separator character. Both the key name and the separator character should be specified in the rendering rules. And if a namerendering like this is required of course. And if and how they should be sorted. But for as long as such a rendering is not made, I would not object to putting the linenumbers in the name tag of the way. It is very useful information, and can be weeded out quite easily if a future render can use the relations. Maarten ___ Talk-be mailing list talk...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Africa Road data import
Hi Robert, 2009/4/22 Robert Soden robert.so...@gmail.com: We've received several emails from folks wanting to help us in this process. Now that we (think) we've got our feet under us, we hope to work with them as we process the remaining data. Wonderful job on the work with UN and the roads import so far. I'd love to help as well if there's still any unassigned job, especially any coding or scripting for preprocessing of the data, but also the de-duping (I'm in an area in Europe that also found a license-compatible source and spent last weeks doing the same de-duping / merging job although now a little short on time). Best of luck with the import ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Any chance of getting RSS/Atom feeds for those changeset/history pages?
On Thu, Apr 23, 2009 at 12:38 AM, Andy Allan gravityst...@gmail.com wrote: On Wed, Apr 22, 2009 at 4:59 PM, Eugene Alvin Villar sea...@gmail.com wrote: Getting RSS/Atom feeds for these seems to be the logical next step. (I prefer Atom 1.0 + GeoRSS extension instead of RSS 2.0, by the way.) I assume that it'd be *extremely* easy to do this: just reformat the current changeset list page's output. You aren't the first to ask for this, but maybe you can go further and be the first to actually log a trac ticket for this enhancement request? http://trac.openstreetmap.org You're right, I missed the mention of people requesting for feeds buried under all that email. :-p Here's the ticket: http://trac.openstreetmap.org/ticket/1737 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Any chance of getting RSS/Atom feeds for those changeset/history pages?
On Thu, Apr 23, 2009 at 1:36 AM, Frederik Ramm frede...@remote.org wrote: Hi, Eugene Alvin Villar wrote: Getting RSS/Atom feeds for these seems to be the logical next step. (I prefer Atom 1.0 + GeoRSS extension instead of RSS 2.0, by the way.) I assume that it'd be *extremely* easy to do this: just reformat the current changeset list page's output. Yes, but as you have perhaps seen, this is sub-optimal in that it gives you many false positives. The bounding box stored with a changeset is a quick indicator about the extents of changes but not so suitable for alerting people or monitoring an area because if someone makes an edit in Madrid and one in Moscow then basically everyone who monitors some place in Europe will have that change on his radar. A proper monitoring function has to use the changeset bbox as an index only and then check whether the changeset *really* contains something in the area of interest to the subscriber. This is more expensive in terms of CPU power and I'm not sure if we want to burden the API with it. It could be done externally if changesets are distributed as OSM diffs are today. Bye Frederik I view the web page and the feed of the changeset/history as simply two different container formats for the same underlying data. So, fixing the bbox problem should be at the source side (before the web page or the feed is generated) instead of as an additional step just for the feed. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] osmosis Problem with bounding-polygon and v0.6?
Hi, I try to cut the planetfile from 2009-04-21 using osmosis: ./bin/osmosis --read-xml-0.6 file=path/planet-090421.osm.bz2 compressionMethod=bzip2 --bp file=path/aoi.pff --write-xml-0.6 file=path/aoi_2009-04-21_v06.osm and get the error message: ... Task 2-bp does not support data provided by default pipe stored at level 1 in the default pipe stack. ... Everything worked with pre-0.6-planetfiles If I use the new planetfile using --read-xml and --write-xml (without 0.6) I get as expected: ... Unable to parse xml file path/planet-090421.osm.bz2. publicId=(null), systemId=(null), lineNumber=6663, columnNumber=34. at com.bretth.osmosis.core.xml.v0_5.XmlReader.run(XmlReader.java:114) at java.lang.Thread.run(Thread.java:636) Caused by: org.xml.sax.SAXParseException: XML document structures must start and end within the same entity. Any idea? Marco P.S. md5sum from planetfile is o.k. using latest-osmosis downloaded today (0.30) no svn-Version ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] New business strategy for Ordnance Survey announced (fwd)]
-- Forwarded message -- Date: Thu, 23 Apr 2009 13:37:16 + From: Jack Kirby jack_ki...@sky.com Reply-To: ordnancem...@yahoogroups.co.uk To: ordnancem...@yahoogroups.co.uk Subject: [ordnancemaps] New business strategy for Ordnance Survey announced A press release containing the latest developments in the great OS charging for data debate. Thursday 23 April 2009 10:47 Communities and Local Government (National) *New business strategy for Ordnance Survey announced* A series of reforms aimed at creating simpler and easier access to geographical data were announced by Housing Minister Iain Wright today. The Government has published a new strategy for the Ordnance Survey, the business responsible for the national mapping of Great Britain, which will improve ease of access to geographic data and services for both commercial and non-commercial use. The strategy will balance the need to maintain the highest quality standards with the need to stimulate innovation in the geographical information market and make data more widely available. The Ordnance Survey will continue to be self-funded and earn revenue by licensing its data, but it will make sure it is easier for customers and other businesses to access its data and services. Iain Wright said: Good maps and location intelligence play an important role in all our lives from plotting pot holes in the road to how we act in a national emergency. We are committed to innovation in the geographical information market, increasing competition and to making geographical data and services more widely available. This new strategy will help the Ordnance Survey thrive in the wider geographical information market that is being transformed by advances in technology and act as a catalyst for innovative business growth and prosperity in the 21st century economy. The strategy focuses on five key areas: * Promoting innovation - with an enhanced free service to allow experimentation with digital information and a clear path from this service to greater commercialisation; * Reforming Ordnance Survey's licensing framework - so that it is much simpler to use Ordnance Survey data and services in other applications; * Reducing costs over time - to ensure that Ordnance Survey continues to offer value-for-money; * Supporting the sharing of information across the public sector - to enable better public policy and services; * Creating an innovative trading entity - to explore further commercial opportunities around Ordnance Survey data and services. The enhanced OS OpenSpace, the digital mapping service that enables innovators to experiment and develop their ideas for free, will be launched on 12 May. The government has set key milestones for delivery over the next year and the Shareholder Executive and Office of Public Sector Information, in consultation with Office Fair Trading, will be involved in regularly reviewing progress. Full details of the strategy can be found at * http://strategy.ordnancesurvey.co.uk*http://strategy.ordnancesurvey.co.uk/. *Notes to Editors* 1. This announcement follows the Trading Funds Assessment, a review looking at how a number of government businesses which charge for information could make information available at no or limited cost. 2. It was announced in the budget that further work on the future business plans and models for specific trading funds, as well as consideration of the effectiveness of the Trading Fund model - will now be incorporated into the Operational Efficiency Programme. 3. The review concluded that the data produced by the Ordnance Survey was more likely to be maintained at high-quality levels under a commercial, revenue-funded model rather than through direct funding from taxation. Ordnance Survey customers told the review team that the quality of the data was important to them, but they wanted Ordnance Survey to provide easier access to it so they can use it more widely in their own business or in new products for consumers. 4. Further details on the findings of the review are available from the Shareholder Executive Website *http://www.shareholderexecutive.gov.uk/*http://www.shareholderexecutive.gov.uk/ Media Enquiries: 020 7944 3049 News Releases: *http://www.communities.gov.uk/newsroom*http://www.communities.gov.uk/newsroom *http://nds.coi.gov.uk/Content/Detail.asp?ReleaseID=399459NewsAreaID=2*http://nds.coi.gov.uk/Content/Detail.asp?ReleaseID=399459NewsAreaID=2 [Non-text portions of this message have been removed] The ordnancemaps group is independent of The Charles Close Society http://www.charlesclosesociety.org.uk and The Ordnance Surveys of Great Britain http://www.ordnancesurvey.co.uk, Northern Ireland http://www.osni.gov.uk/ and Ireland http://www.osi.ie/ . Members may wish to check out past emails to the group in the ordnancemaps archive at http://www.yahoogroups.com/group/ordnancemapsYahoo! Groups Links * To visit your group
Re: [OSM-talk] Placeopedia replacement
Placeopedia is a project by mySociety, allies to OpenStreetMap. They've used OSM in the Time Travel Maps project .. http://www.mysociety.org/2007/more-travel-maps/ So, I'd suggest approaching them on one of their mailing lists and suggesting the change. Or I believe the code is open source, so you could just go ahead and start a new site. Use Mapstraction to easily switch from Google to OSM. -Mikel From: Mike Ryan mike.r...@redmar.com To: talk@openstreetmap.org Sent: Thursday, April 23, 2009 2:04:56 AM Subject: [OSM-talk] Placeopedia replacement ce, All I used to use a site called placeopedia that showed a map with Wikipedia articles located on it. http://www.placeopedia.com/ Quite useful if you're planning a route and you want to see interesting sights slong the way Is anyone aware of a similar openstreetmap replacment? Cheers Mike ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wrong scale in slippy map
Jukka Rahkonen wrote: I believe also that the scale bar is not right. Distorsion is one thing, it makes Sweden (and Finland) to look visually ridiculous on the map, At the deep zoom levels (zoom=6 and higher numbers), Sweden and Finland don't look large, because you don't see other countries on the same screen. At these deep zoom levels, the difference in scale between the top and bottom of the screen is also small. Google Maps uses the same map projection, as do all tile-based online maps. The projection is not the problem. Google Maps shows the correct scale and it changes as you pan north and south within the same zoom level. See for example http://maps.google.com/?ll=57,17z=6 At zoom=5 and lower numbers, where you see whole continents or the whole world, Sweden and Finland look large in comparison to Britain or Spain. That is sad. Perhaps a different projection could be used for these zoom levels? It would make the whole system a lot more complicated. Google Earth shows you a globe as you zoom out, instead of the flat map in Google Maps. -- Lars Aronsson (l...@aronsson.se) Aronsson Datateknik - http://aronsson.se ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] mapnik weekly rendering after API 0.6
Out of interest, since Mapnik seems to process the entire world quite quickly, why is it not invoked when a tile is dirty, like osmarender? It is. Either a tile is requested in real-time (if it doesn't exist) or is queued if the tile is old (via render_old). mod_tile is an amazing piece of software indeed. Some areas which have been updated but don't show up in Mapnik as changed at all: http://openstreetmap.org/?lat=51.40296lon=-0.02184zoom=16layers=B000FTF http://openstreetmap.org/?lat=51.03081lon=-2.68463zoom=15layers=0B00FTF Oddly enough when I view them on Sautter, they are considerably better (every few hours) http://sautter.com/map/?zoom=16lat=51.40231lon=-0.02272layers=B0FFFT ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Turn restrictions ambiguity
I don't see a clear explanation as to why there is ambiguity if you don't do turn restrictions at the end of ways on the wiki. There is some stuff in the talk page http://wiki.openstreetmap.org/wiki/Talk:Relation:restriction Anyone care to provide an explanation? The reason I ask is that I've come across some roads where there is a restriction every other turn in both directions... and splitting a mile long road in to 30 pieces seems nuts. As a follow up, I can guess, but what will the renderer do in that situation? I'm guessing mapnik will give up trying to put 30 names on a one mile road and won't notice they're the same name? Best Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-legal-talk] Substantial meaning
Has there been any discussion on what people here feel 'substantial' means in the context of the definitions of the ODbL? I've banged around the wiki looking but might might have missed it. Here's the first important bit relevant to this in the ODbL: Extraction – Means the permanent or temporary transfer of all or a Substantial part of the Data to another medium by any means or in any form. Which I believe follows the language of the EU database directive. Basically, what do we feel substantial means when someone takes some part of the data? How much is 'substantial'? I won't frame the question further as I can see a number of ways and we, the license working group, would like to get a feel for the communities views. We're not looking for a legal opinion on that here, clearly case law one day has to play a role. Rather, what do we think it means? Best Steve ___ legal-talk mailing list legal-t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] Turn restrictions ambiguity
On Thu, 23 Apr 2009 21:34:05 +0300, SteveC st...@asklater.com wrote: I don't see a clear explanation as to why there is ambiguity if you don't do turn restrictions at the end of ways on the wiki. There is some stuff in the talk page http://wiki.openstreetmap.org/wiki/Talk:Relation:restriction Anyone care to provide an explanation? The reason I ask is that I've come across some roads where there is a restriction every other turn in both directions... and splitting a mile long road in to 30 pieces seems nuts. As a follow up, I can guess, but what will the renderer do in that situation? I'm guessing mapnik will give up trying to put 30 names on a one mile road and won't notice they're the same name? If both from and to ways continue after the via point and neither is one-way, there's two possible ways to interpret it: the restriction could apply when coming from either of the ends of the from-way. This of course doesn't matter if there is similar restriction coming from both directions, but that's not nearly always the case. And even if there is symmetry in the real life restrictions, it's not appropriate in my opinion to map those with just one restriction. About the splitting, it's already necessary to split the way if some other property changes, eg. speed limit or number of lanes (which does change more often in some places than there are restrictions), it's either the renderer's job to figure out that the pieces belong together or we could use some relation to group the pieces together but that too would require support from the renderers. Best Steve Regards Teemu Koskinen ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Turn restrictions ambiguity
On 23 Apr 2009, at 12:17, Teemu Koskinen wrote: On Thu, 23 Apr 2009 21:34:05 +0300, SteveC st...@asklater.com wrote: I don't see a clear explanation as to why there is ambiguity if you don't do turn restrictions at the end of ways on the wiki. There is some stuff in the talk page http://wiki.openstreetmap.org/wiki/Talk:Relation:restriction Anyone care to provide an explanation? The reason I ask is that I've come across some roads where there is a restriction every other turn in both directions... and splitting a mile long road in to 30 pieces seems nuts. As a follow up, I can guess, but what will the renderer do in that situation? I'm guessing mapnik will give up trying to put 30 names on a one mile road and won't notice they're the same name? If both from and to ways continue after the via point and neither is one-way, there's two possible ways to interpret it: the restriction could apply when coming from either of the ends of the from-way. This of course doesn't matter if there is similar restriction coming from both directions, but that's not nearly always the case. And even if there is symmetry in the real life restrictions, it's not appropriate in my opinion to map those with just one restriction. eh? don't you assign direction by saying 'from' and 'to' ? About the splitting, it's already necessary to split the way if some other property changes, eg. speed limit or number of lanes (which does change more often in some places than there are restrictions), it's either the renderer's job to figure out that the pieces belong together or we could use some relation to group the pieces together but that too would require support from the renderers. Yes - but turn restriction splitting will lead to much, much more splits Best Steve Regards Teemu Koskinen Best Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Turn restrictions ambiguity
On Thu, 23 Apr 2009 22:25:36 +0300, SteveC st...@asklater.com wrote: On 23 Apr 2009, at 12:17, Teemu Koskinen wrote: On Thu, 23 Apr 2009 21:34:05 +0300, SteveC st...@asklater.com wrote: I don't see a clear explanation as to why there is ambiguity if you don't do turn restrictions at the end of ways on the wiki. There is some stuff in the talk page http://wiki.openstreetmap.org/wiki/Talk:Relation:restriction Anyone care to provide an explanation? The reason I ask is that I've come across some roads where there is a restriction every other turn in both directions... and splitting a mile long road in to 30 pieces seems nuts. As a follow up, I can guess, but what will the renderer do in that situation? I'm guessing mapnik will give up trying to put 30 names on a one mile road and won't notice they're the same name? If both from and to ways continue after the via point and neither is one-way, there's two possible ways to interpret it: the restriction could apply when coming from either of the ends of the from-way. This of course doesn't matter if there is similar restriction coming from both directions, but that's not nearly always the case. And even if there is symmetry in the real life restrictions, it's not appropriate in my opinion to map those with just one restriction. eh? don't you assign direction by saying 'from' and 'to' ? Yes in the sense of which of the two ways you are coming from, but if the way is not one-way and it doesn't end at the via-node, there's two possible directions from where you can come to the via-node using the way. Regards Teemu Koskinen ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Turn restrictions ambiguity
SteveC wrote: On 23 Apr 2009, at 12:17, Teemu Koskinen wrote: If both from and to ways continue after the via point and neither is one-way, there's two possible ways to interpret it: the restriction could apply when coming from either of the ends of the from-way. This of course doesn't matter if there is similar restriction coming from both directions, but that's not nearly always the case. And even if there is symmetry in the real life restrictions, it's not appropriate in my opinion to map those with just one restriction. eh? don't you assign direction by saying 'from' and 'to' ? |A | | x| B ---*-- | | | Imagine this situation, ways A and B with a common node x. You are moving on A from north to south and are not allowed to turn into B. If you create a restriction no_left_turn from A to B via x, you will also prevent that cars moving from south to north on A can turn left. This is usually not intended. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Turn restrictions ambiguity
On 23 Apr 2009, at 12:32, Teemu Koskinen wrote: On Thu, 23 Apr 2009 22:25:36 +0300, SteveC st...@asklater.com wrote: On 23 Apr 2009, at 12:17, Teemu Koskinen wrote: On Thu, 23 Apr 2009 21:34:05 +0300, SteveC st...@asklater.com wrote: I don't see a clear explanation as to why there is ambiguity if you don't do turn restrictions at the end of ways on the wiki. There is some stuff in the talk page http://wiki.openstreetmap.org/wiki/Talk:Relation:restriction Anyone care to provide an explanation? The reason I ask is that I've come across some roads where there is a restriction every other turn in both directions... and splitting a mile long road in to 30 pieces seems nuts. As a follow up, I can guess, but what will the renderer do in that situation? I'm guessing mapnik will give up trying to put 30 names on a one mile road and won't notice they're the same name? If both from and to ways continue after the via point and neither is one-way, there's two possible ways to interpret it: the restriction could apply when coming from either of the ends of the from-way. This of course doesn't matter if there is similar restriction coming from both directions, but that's not nearly always the case. And even if there is symmetry in the real life restrictions, it's not appropriate in my opinion to map those with just one restriction. eh? don't you assign direction by saying 'from' and 'to' ? Yes in the sense of which of the two ways you are coming from, but if the way is not one-way and it doesn't end at the via-node, there's two possible directions from where you can come to the via- node using the way. Um... no. The restriction has handedness - left or right... and the way coming off it has an angle.. lets try some ascii B | | |--C | | | A I am going from A to B. There is no 'right_turn' restriction on the corner that stops me turning to C. That cannot be interpreted as a restriction from B to A as it would be a left turn, not a right turn. To figure that out you just need to compute the angle it makes with your direction of travel to see if it's left or right? Regards Teemu Koskinen Best Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Turn restrictions ambiguity
On 23 Apr 2009, at 12:34, Tobias Knerr wrote: SteveC wrote: On 23 Apr 2009, at 12:17, Teemu Koskinen wrote: If both from and to ways continue after the via point and neither is one-way, there's two possible ways to interpret it: the restriction could apply when coming from either of the ends of the from-way. This of course doesn't matter if there is similar restriction coming from both directions, but that's not nearly always the case. And even if there is symmetry in the real life restrictions, it's not appropriate in my opinion to map those with just one restriction. eh? don't you assign direction by saying 'from' and 'to' ? |A | | x| B ---*-- | | | Imagine this situation, ways A and B with a common node x. You are moving on A from north to south and are not allowed to turn into B. If you create a restriction no_left_turn from A to B via x, you will also prevent that cars moving from south to north on A can turn left. This is usually not intended. Ah gotcha! Ok so in that case... why don't we make best practice to split your way A in to two directions, rather than hundreds of little ways? Best Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] osmosis Problem with bounding-polygon and v0.6?
hi karl, ./bin/osmosis --read-xml-0.6 file=path/planet-090421.osm.bz2 compressionMethod=bzip2 --bounding-polygon-0.6 file=path/aoi.pff --write-xml-0.6 file=path/aoi_2009-04-21_v06.osm gives (almost) the same error as pure v0.5: Unable to parse xml file path/planet-090421.osm.bz2. publicId=(null), systemId=(null), lineNumber=6663, columnNumber=34. at com.bretth.osmosis.core.xml.v0_6.XmlReader.run(XmlReader.java:114) at java.lang.Thread.run(Thread.java:636) Caused by: org.xml.sax.SAXParseException: XML document structures must start and end within the same entity. Marco Karl Newman schrieb: On Thu, Apr 23, 2009 at 7:06 AM, Marco Lechner - FOSSGIS e.V. marco.lech...@fossgis.de mailto:marco.lech...@fossgis.de wrote: Hi, I try to cut the planetfile from 2009-04-21 using osmosis: ./bin/osmosis --read-xml-0.6 file=path/planet-090421.osm.bz2 compressionMethod=bzip2 --bp file=path/aoi.pff --write-xml-0.6 file=path/aoi_2009-04-21_v06.osm and get the error message: ... Task 2-bp does not support data provided by default pipe stored at level 1 in the default pipe stack. ... Everything worked with pre-0.6-planetfiles If I use the new planetfile using --read-xml and --write-xml (without 0.6) I get as expected: ... Unable to parse xml file path/planet-090421.osm.bz2. publicId=(null), systemId=(null), lineNumber=6663, columnNumber=34. at com.bretth.osmosis.core.xml.v0_5.XmlReader.run(XmlReader.java:114) at java.lang.Thread.run(Thread.java:636) Caused by: org.xml.sax.SAXParseException: XML document structures must start and end within the same entity. Any idea? Marco P.S. md5sum from planetfile is o.k. using latest-osmosis downloaded today (0.30) no svn-Version You had part of it right, but you need to specify 0.6 for all elements of the pipeline, including the bounding polygon task. So try using --bounding-polygon-0.6 instead of --bp. In the next release of Osmosis I believe all the tasks will default to 0.6 instead of 0.5 so you won't have to add the -0.6 suffix to the tasks. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Turn restrictions ambiguity
On Thu, Apr 23, 2009 at 14:45, David Lynch djly...@gmail.com wrote: On Thu, Apr 23, 2009 at 14:25, SteveC st...@asklater.com wrote: If both from and to ways continue after the via point and neither is one-way, there's two possible ways to interpret it: the restriction could apply when coming from either of the ends of the from-way. This of course doesn't matter if there is similar restriction coming from both directions, but that's not nearly always the case. And even if there is symmetry in the real life restrictions, it's not appropriate in my opinion to map those with just one restriction. eh? don't you assign direction by saying 'from' and 'to' ? To use a bit of ASCII art: (best viewed in monospace font) (1) | B | (2)--A--(3)--A--(4) | B | (5) A turn restriction from way A onto way B via node 3 of no left turn doesn't specify whether the left turn is from Node 2 towards Node 1, from Node 4 towards Node 5, or both. IMO, adding a from_node role for the last node before the intersection and a to_node for the first node after the intersection would be the way to get rid of the ambiguity without requiring a lot of splitting. -- David J. Lynch djly...@gmail.com -- David J. Lynch djly...@gmail.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Turn restrictions ambiguity
2009/4/23 SteveC st...@asklater.com: On 23 Apr 2009, at 12:32, Teemu Koskinen wrote: On Thu, 23 Apr 2009 22:25:36 +0300, SteveC st...@asklater.com wrote: On 23 Apr 2009, at 12:17, Teemu Koskinen wrote: On Thu, 23 Apr 2009 21:34:05 +0300, SteveC st...@asklater.com wrote: I don't see a clear explanation as to why there is ambiguity if you don't do turn restrictions at the end of ways on the wiki. There is some stuff in the talk page http://wiki.openstreetmap.org/wiki/Talk:Relation:restriction Anyone care to provide an explanation? The reason I ask is that I've come across some roads where there is a restriction every other turn in both directions... and splitting a mile long road in to 30 pieces seems nuts. As a follow up, I can guess, but what will the renderer do in that situation? I'm guessing mapnik will give up trying to put 30 names on a one mile road and won't notice they're the same name? If both from and to ways continue after the via point and neither is one-way, there's two possible ways to interpret it: the restriction could apply when coming from either of the ends of the from-way. This of course doesn't matter if there is similar restriction coming from both directions, but that's not nearly always the case. And even if there is symmetry in the real life restrictions, it's not appropriate in my opinion to map those with just one restriction. eh? don't you assign direction by saying 'from' and 'to' ? Yes in the sense of which of the two ways you are coming from, but if the way is not one-way and it doesn't end at the via-node, there's two possible directions from where you can come to the via- node using the way. Um... no. The restriction has handedness - left or right... and the way coming off it has an angle.. lets try some ascii B | | |--C | | | A I am going from A to B. There is no 'right_turn' restriction on the corner that stops me turning to C. That cannot be interpreted as a restriction from B to A as it would be a left turn, not a right turn. To figure that out you just need to compute the angle it makes with your direction of travel to see if it's left or right? The no_left_turn, no_right_turn is only to indicate the type of streetsign to show AFAIU. Practically, adding angles to the specification will be a hell to implementers, and there are few use cases that would benefit from this. Sometimes you will have a way splitting off to C that first turns slightly left, enters a tunnel or viaduct and then goes on the other side of AB, something that at low zoom level looks as in your drawing, and the streetsign might stilll be no_right_turn. Or something like this is common: B C \ | \ | \| | | A where the straight line is considered a turn even though it's straight, and the turn from A to B is considered straight even though it's an arc :P Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Turn restrictions ambiguity
SteveC schrieb: Ok so in that case... why don't we make best practice to split your way A in to two directions, rather than hundreds of little ways? You mean something like that ^A1 |A2 | | | | | | B ---*-*-- | | | | | v with both A1 and A2 being oneways? It's possible, but should probably be done only if the two directions are separated in reality. Otherwise, this will affect the possibility of turning. It also isn't great that the user sees two roads where only one exists in reality. You also have to deal with navigation software announcing two junctions instead of one, and so on. If you then consider that applications don't interpret anything except the no_/only_-prefix and aren't expected to care about the rest of the value (left, right and straight on being nontrivial concepts for software), you'd have to create two directions for B, too. At that point, it's probably best to just split A at junctions and be done with it. Tobias Knerr PS: I'd really love to see a feature to select ways between *click1* and *click2* in editors. Would make all that way-splitting much less of a problem. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] osmosis Problem with bounding-polygon and v0.6?
On Thu, Apr 23, 2009 at 12:39 PM, Marco Lechner - FOSSGIS e.V. marco.lech...@fossgis.de wrote: hi karl, ./bin/osmosis --read-xml-0.6 file=path/planet-090421.osm.bz2 compressionMethod=bzip2 --bounding-polygon-0.6 file=path/aoi.pff --write-xml-0.6 file=path/aoi_2009-04-21_v06.osm gives (almost) the same error as pure v0.5: Unable to parse xml file path/planet-090421.osm.bz2. publicId=(null), systemId=(null), lineNumber=6663, columnNumber=34. at com.bretth.osmosis.core.xml.v0_6.XmlReader.run(XmlReader.java:114) at java.lang.Thread.run(Thread.java:636) Caused by: org.xml.sax.SAXParseException: XML document structures must start and end within the same entity. Marco So, it sounds like you had multiple problems. Probably your planet file is corrupt. You could try to look at the referenced line (6663) in the unpacked file and see if it is valid XML. Most likely you will need to re-download the planet file. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Turn restrictions ambiguity
If one were to refer to nodes on the two ways instead of the way itself, it would remove the ambiguity wouldn't it? Albeit more complicated for the consumer to work out, in that it would have to decide which way the two nodes were on. |A *a | c| b -*---*---*--B | | * | from a to b via c, rather than from A to B via c David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wrong scale in slippy map
But this is not flawless. For instance here it's as if Canada was 200km wide and Europe Asia combined 300 miles wide. http://maps.google.com/?ie=UTF8ll=87.797228,-38.671875spn=51.090044,360z=1 Yann Le 23 avr. 09 à 16:23, Lars Aronsson a écrit : Google Maps shows the correct scale and it changes as you pan north and south within the same zoom level. See for example http://maps.google.com/?ll=57,17z=6 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Turn restrictions ambiguity
On Thu, 23 Apr 2009 21:56:09 +0200, andrzej zaborowski balr...@gmail.com wrote: 2009/4/23 SteveC st...@asklater.com: On 23 Apr 2009, at 12:32, Teemu Koskinen wrote: On Thu, 23 Apr 2009 22:25:36 +0300, SteveC st...@asklater.com wrote: On 23 Apr 2009, at 12:17, Teemu Koskinen wrote: On Thu, 23 Apr 2009 21:34:05 +0300, SteveC st...@asklater.com wrote: I don't see a clear explanation as to why there is ambiguity if you don't do turn restrictions at the end of ways on the wiki. There is some stuff in the talk page http://wiki.openstreetmap.org/wiki/Talk:Relation:restriction Anyone care to provide an explanation? The reason I ask is that I've come across some roads where there is a restriction every other turn in both directions... and splitting a mile long road in to 30 pieces seems nuts. As a follow up, I can guess, but what will the renderer do in that situation? I'm guessing mapnik will give up trying to put 30 names on a one mile road and won't notice they're the same name? If both from and to ways continue after the via point and neither is one-way, there's two possible ways to interpret it: the restriction could apply when coming from either of the ends of the from-way. This of course doesn't matter if there is similar restriction coming from both directions, but that's not nearly always the case. And even if there is symmetry in the real life restrictions, it's not appropriate in my opinion to map those with just one restriction. eh? don't you assign direction by saying 'from' and 'to' ? Yes in the sense of which of the two ways you are coming from, but if the way is not one-way and it doesn't end at the via-node, there's two possible directions from where you can come to the via- node using the way. Um... no. The restriction has handedness - left or right... and the way coming off it has an angle.. lets try some ascii B | | |--C | | | A I am going from A to B. There is no 'right_turn' restriction on the corner that stops me turning to C. That cannot be interpreted as a restriction from B to A as it would be a left turn, not a right turn. To figure that out you just need to compute the angle it makes with your direction of travel to see if it's left or right? The no_left_turn, no_right_turn is only to indicate the type of streetsign to show AFAIU. Practically, adding angles to the specification will be a hell to implementers, and there are few use cases that would benefit from this. Sometimes you will have a way splitting off to C that first turns slightly left, enters a tunnel or viaduct and then goes on the other side of AB, something that at low zoom level looks as in your drawing, and the streetsign might stilll be no_right_turn. Or something like this is common: B C \ | \ | \| | | A where the straight line is considered a turn even though it's straight, and the turn from A to B is considered straight even though it's an arc :P Cheers So how do you mean to tag a no_left_turn, where it is marked with a fully drawn yellow line in the center of a road, but no sign? The restriction to tag must correspodent with the actual restriction, so that a routing engine will route you correctly even if there are no visible signs. Sometimes restrictions can be painted in the lanes (one lane with arrow to the right, and one straight ahead, but no lane with arrow to the left). The choise of lane will than correspodent with where you are going, I guess that type of routing might come in another relation. A ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Turn restrictions ambiguity
2009/4/23 Aun Johnsen (via Webmail) skipp...@gimnechiske.org: On Thu, 23 Apr 2009 21:56:09 +0200, andrzej zaborowski balr...@gmail.com wrote: Or something like this is common: B C \ | \ | \| | | A where the straight line is considered a turn even though it's straight, and the turn from A to B is considered straight even though it's an arc :P Cheers So how do you mean to tag a no_left_turn, where it is marked with a fully drawn yellow line in the center of a road, but no sign? The restriction to tag must correspodent with the actual restriction, so that a routing engine will route you correctly even if there are no visible signs. The routing engine will already route you correctly if it follows the specification on the wiki page, taking only the no_ / only_ part of the tag into account. Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Turn restrictions ambiguity
David Earl schrieb: If one were to refer to nodes on the two ways instead of the way itself, it would remove the ambiguity wouldn't it? There was a proposal that suggested exactly that, xrestriction: http://wiki.openstreetmap.org/index.php?title=Relation:xrestriction Hasn't been used a lot. Also, the wiki page has apparently been deleted. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Turn restrictions ambiguity
On 23 Apr 2009, at 22:56, andrzej zaborowski wrote: 2009/4/23 SteveC st...@asklater.com: On 23 Apr 2009, at 12:32, Teemu Koskinen wrote: On Thu, 23 Apr 2009 22:25:36 +0300, SteveC st...@asklater.com wrote: On 23 Apr 2009, at 12:17, Teemu Koskinen wrote: On Thu, 23 Apr 2009 21:34:05 +0300, SteveC st...@asklater.com wrote: I don't see a clear explanation as to why there is ambiguity if you don't do turn restrictions at the end of ways on the wiki. There is some stuff in the talk page http://wiki.openstreetmap.org/wiki/Talk:Relation:restriction Anyone care to provide an explanation? The reason I ask is that I've come across some roads where there is a restriction every other turn in both directions... and splitting a mile long road in to 30 pieces seems nuts. As a follow up, I can guess, but what will the renderer do in that situation? I'm guessing mapnik will give up trying to put 30 names on a one mile road and won't notice they're the same name? If both from and to ways continue after the via point and neither is one-way, there's two possible ways to interpret it: the restriction could apply when coming from either of the ends of the from-way. This of course doesn't matter if there is similar restriction coming from both directions, but that's not nearly always the case. And even if there is symmetry in the real life restrictions, it's not appropriate in my opinion to map those with just one restriction. eh? don't you assign direction by saying 'from' and 'to' ? Yes in the sense of which of the two ways you are coming from, but if the way is not one-way and it doesn't end at the via-node, there's two possible directions from where you can come to the via- node using the way. Um... no. The restriction has handedness - left or right... and the way coming off it has an angle.. lets try some ascii B | | |--C | | | A I am going from A to B. There is no 'right_turn' restriction on the corner that stops me turning to C. That cannot be interpreted as a restriction from B to A as it would be a left turn, not a right turn. To figure that out you just need to compute the angle it makes with your direction of travel to see if it's left or right? The no_left_turn, no_right_turn is only to indicate the type of streetsign to show AFAIU. Practically, adding angles to the specification will be a hell to implementers, and there are few use cases that would benefit from this. Sometimes you will have a way splitting off to C that first turns slightly left, enters a tunnel or viaduct and then goes on the other side of AB, something that at low zoom level looks as in your drawing, and the streetsign might stilll be no_right_turn. Or something like this is common: B C \ | \ | \| | | A where the straight line is considered a turn even though it's straight, and the turn from A to B is considered straight even though it's an arc :P This is yet another kettle of fish of how do you get the routing engine to tell you when the general flow of traffic is from A - B, even so the road name of A is the same a C, but different to B. I have come across a lot of these on my travels, and still haven't come up with a way to tag it. Shaun ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Turn restrictions ambiguity
On Thu, Apr 23, 2009 at 9:16 PM, David Earl da...@frankieandshadow.com wrote: If one were to refer to nodes on the two ways instead of the way itself, it would remove the ambiguity wouldn't it? Albeit more complicated for the consumer to work out, in that it would have to decide which way the two nodes were on. an alternative is to use the implicit direction of each way where there is ambiguity, as is done for oneway. this would mean all combinations can be uniquely resolved without way splitting or explicit reference to nodes. it is also forward-compatible with the existing scheme. it would seem that the most user-friendly way of presenting this would be built-in editor support*, e.g: by drawing an arrow from one way to the other showing the disallowed route, rather than expecting users to parse the relation themselves. cheers, matt * i know, i know, patches welcome, etc... ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [talk-ph] Reviving plan(s) for Tagaytay Mapping party
OK to, we can share mapping/surveying techniques in the mapping event :) What I do is: 1. old school - gps and notebook 2. gps and geotagged photo I think ed do voicemapping. Rally, maybe you can try synchronizing your notes to the gps timestamp automatically. Something like someone encodes the feature in a chat client and then link it to the timestamp of the gps. This approach can be good for a two-person mapping in a car. (I can be third person holding the potato chips and beer. hehehe) On Fri, Apr 24, 2009 at 12:56 PM, ian lopez ian_lopez_1...@yahoo.com wrote: it can be all of the above. one team concentrates on business establishments, the other on roads. also, we need to slice up the Tagaytay cake. Yes, it's possible for one to take waypoints while a vehicle is moving, provided that one act fast enough to take it. --- On Fri, 4/24/09, Rally de Leon rall...@gmail.com wrote: From: Rally de Leon rall...@gmail.com Subject: Re: [talk-ph] Reviving plan(s) for Tagaytay Mapping party To: Nacario Neil nbnaca...@yahoo.com Cc: maning sambale emmanuel.samb...@gmail.com, ian lopez ian_lopez_1...@yahoo.com, OSM talk...@openstreetmap.org Date: Friday, April 24, 2009, 11:27 AM i have 2 handheld gps (plus a netbook with external gps antenna) and a car; but with limited budget for the gas to tagaytay, since i'm coming from rizal. maybe we can join together, patak-patak sa fuel and merienda para tipid. it's faster if one drives and the other one writes notes or type waypoints name directly to the pc, another one holds the potato chips, and another one jumps in and out of car to take waypoints of business establishments on walkways and peripheries within a commercial area. how will the mapping be done anyway? by bike, by car, by foot or all of the above? which is the priority, roads tracks or business waypoints? On Fri, Apr 24, 2009 at 10:47 AM, Nacario Neil nbnaca...@yahoo.com wrote: I am new here and I am interested. But I only have a limited resource available for mapping: 1. gps 2. pair of shoes for walking 3. saturdays and sundays as free times - Original Message From: maning sambale emmanuel.samb...@gmail.com To: ian lopez ian_lopez_1...@yahoo.com Cc: OSM talk...@openstreetmap.org Sent: Wednesday, April 22, 2009 4:20:29 PM Subject: Re: [talk-ph] Reviving plan(s) for Tagaytay Mapping party Sana at least we have 5 people joining. Sino pa sali? On Wed, Apr 22, 2009 at 4:14 PM, ian lopez ian_lopez_1...@yahoo.com wrote: +1, availability at 85% --- On Wed, 4/22/09, maning sambale emmanuel.samb...@gmail.com wrote: From: maning sambale emmanuel.samb...@gmail.com Subject: Re: [talk-ph] Reviving plan(s) for Tagaytay Mapping party To: osm-ph talk...@openstreetmap.org Date: Wednesday, April 22, 2009, 3:29 PM May 18 or 19? On Wed, Apr 22, 2009 at 9:09 AM, Eugene Alvin Villar sea...@gmail.com wrote: Game! I prefer sometime in May. On Tue, Apr 21, 2009 at 9:37 PM, ian lopez ian_lopez_1...@yahoo.com wrote: After the holy week break and the recently-concluded API update, I was wondering if the OSMers in the Philippines can revive a long-dormat plan for a mapping party, specifically in Tagaytay (as previously discussed). It has been at least a month since we came close to organizing one. Do you want to give it another try? ___ talk-ph mailing list talk...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- http://vaes9.codedgraphic.com ___ talk-ph mailing list talk...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- cheers, maning -- Freedom is still the
Re: [Talk-de] Garminkarte für ganz Deutschland
Hallo, Stephan Wolff wrote: Was sollen redundante Informationen in einer Datenbank? Redundante Informationen sind ueberfluessig, die Frage ist eher, was genau redundant ist. Unsere Datenbank unterstuetzt 7 Nachkommastellen bei der geografischen Laenge und Breite, das sind nach meiner Rechnung am Aequator 1cm Genauigkeit. Wenn wir jetzt sagen, dass 10cm Genauigkeit auch reicht, dann koennen wir ja einfach die 7. Nachkommastelle wegrunden. Oder wenn uns eine Genauigkeit von 1m reicht, dann runden wir alles auf 5 Stellen... Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin Deutschland update
Bernd Wurst schrieb: Die Gefahr ist natürlich, dass dann manche Sachen doppelt drin sind, weil manche die Tags an das Gebäude haun und zusätzlich noch nen Punkt anlegen, wobei das ja eher ein Datenfehler ist. mkgmap prüft das. Wenn im nahen Umkreis des neu erzeugten Punktes schon ein Punkt mit gleichen Eigenschaften ist, wird nur einer eingetragen. Wow, das wusst ich auch nicht. Wenn ich jetzt noch mein Auto-über-Fußweg routing problem hinbekomme, bin ich rundum glücklich! Weiß jemand im Detail, wie das routing mit mkgmap funktioniert. Ich hab ehrlich gesagt nur das default style file genommen und mir irgendwas zusammengereimt. Was bedeutet road_class und road_speed genau? Welche Werte sind dort überhaupt möglich? Grüße Christoph signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin Deutschland update
Christoph Wagner schrieb: Was bedeutet road_class und road_speed genau? Welche Werte sind dort überhaupt möglich? Info von Steve zu road_speed: This is a rough guide. From the cgpsmapper manual. 7 128 km/h 6 108 km/h 5 93 km/h 4 72 km/h 3 56 km/h 2 40 km/h 1 20 km/h 0 8 km/h (ferry) Experimenting for the best results is probably best. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin Deutschland update
Hallo. Am Donnerstag 23 April 2009 09:47:11 schrieb Christoph Wagner: mkgmap prüft das. Wenn im nahen Umkreis des neu erzeugten Punktes schon ein Punkt mit gleichen Eigenschaften ist, wird nur einer eingetragen. Wow, das wusst ich auch nicht. Ah, moment mal, ich glaub ich hab da was verwechselt, sorry. Aber dennoch: Wenn beides eingetragen ist, ist das doppelte Information und ich habe kein Problem damit, dass diese doppelte Information dann zu doppelten Ergebnissen führt. Schlimmer wäre es, wenn korrekt als Fläche erfasste POIs nicht gefunden werden können. Gruß, Bernd -- Hoffnung ist nur ein Mangel an Information. 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] Panoramio
Martin ddfsk.ba...@googlemail.com writes: Danke genau das was? wars was ich gesucht habe. :) Schön. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Garminkarte für die ganze Welt - Worl dfile vom 21.4.09
Hallo, das neue Worldfile steht wie immer zum Download bereit unter: http://wiki.openstreetmap.org/wiki/User:Computerteddy Als Neuigkeit habe ich anzubieten, daß der Welt-Kachelsatz jetzt eine funktionierende Vorschaukarte hat, es kann also in Kartenprogramme die ganze Welt eingebunden werden. -- Viele Gruesse Computerteddy ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin Deutschland update
Chris-Hein Lunkhusen schrieb: Christoph Wagner schrieb: Was bedeutet road_class und road_speed genau? Welche Werte sind dort überhaupt möglich? Info von Steve zu road_speed: This is a rough guide. From the cgpsmapper manual. 7 128 km/h 6 108 km/h 5 93 km/h 4 72 km/h 3 56 km/h 2 40 km/h 1 20 km/h 0 8 km/h (ferry) Experimenting for the best results is probably best. Ich nehme an das ist die anzunehmende Gescwindigkeit fürs routing und nicht für maxspeed? Wie werden den die Werte aus den OSM-Daten umgesetzt? Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte für ganz Deutschland
Moin, Frederik Ramm schrieb: Was sollen redundante Informationen in einer Datenbank? Redundante Informationen sind ueberfluessig, die Frage ist eher, was genau redundant ist. Unsere Datenbank unterstuetzt 7 Nachkommastellen bei der geografischen Laenge und Breite, das sind nach meiner Rechnung am Aequator 1cm Genauigkeit. Wenn wir jetzt sagen, dass 10cm Genauigkeit auch reicht, dann koennen wir ja einfach die 7. Nachkommastelle wegrunden. Oder wenn uns eine Genauigkeit von 1m reicht, dann runden wir alles auf 5 Stellen... Es ging um eine zu hohe Punktdichte auf Wegen. Es gibt einige nahezu gerade Wege, die aus offenbar im Sekundentakt aufgezeichneten GPS-Datenpunkten bestehen. Eine mögliche Definition redundanter Punkte wäre: Wegpunkte, die keine Tags haben, einen Knickwinkel zwischen 170 und 190 Grad bilden, seit 14 Tagen unverändert sind und deren Entfernung den Weg um maximal 1m verändert. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] living_street + maxspeed 7
Garry schrieb: Mario Salvini schrieb: Es gibt auch verkehrsberuhigungen die nicht als offizielle verkehrsberuihgte Zone mit diesem blauen Schild ausgewiesen sind. Garry das sind aber doch dann normale highway=residential Straßen... Mein Stand der Dinge ist, das living_street nur für Spielstraßen gedacht ist. In einer Spielstrasse gilt quasi maxspeed=0km/h da dort überhaupt nicht gefahren werden darf (Durchfahrt veboten mit Zusatzschild ballspielendes Kind). Gemeint ist wohl ehr verkehrsberuhigter Bereich. mein Fehler. meinte natürlich verkehrsberuhigte Zone. Da auf dem Schild auch ein Kind spielt kommt das bei mir oft in einem Atemzug. Deshalb ist eigenltich auch eine zusätzliche maxspeed-Angabe überflüssig, weil ja das implizierte Limit immer gilt. Erfordert dann aber wieder mehr intelligenz in der Anwendung - es muss gegebenfalls geprüft werden in welchem Land man sich befindet und auf was für einer Strassenkategorie. da kommen wir so oder so nicht rum. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] living_street + maxspeed 7
Am 23. April 2009 00:32 schrieb Garry garr...@gmx.de: Stimmt nicht ganz - Durchfahrt verboten mit einem _Zusatzschild das ein ballspielendes Kind symbolisiert gilt als Spielstrasse - maxspeed = 0 da jeglicher Verkehr verboten Ist das dann nicht eigentlich gleichbedeutend mit highway=footway? Aber ich denke es wird doch eher mit highway=residential, access=no, foot=yes getagt, oder? Vielleicht noch leisure=playground dazu. ;) Rolf ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin Deutschland update
Chris-Hein Lunkhusen schrieb: Christoph Wagner schrieb: Was bedeutet road_class und road_speed genau? Welche Werte sind dort überhaupt möglich? Info von Steve zu road_speed: This is a rough guide. From the cgpsmapper manual. 7 128 km/h 6 108 km/h 5 93 km/h 4 72 km/h 3 56 km/h 2 40 km/h 1 20 km/h 0 8 km/h (ferry) Experimenting for the best results is probably best. Sehr interessant. Und was genau kann dann die road_class? signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Garminkarte Doku update
Hallo liste, hab heute mal das gröbste an Doku ins Wiki gehaun, was ich so weiß. http://wiki.openstreetmap.org/wiki/DE:All_in_one_Garmin_Map Featurewünsche sind ab sofort dort zu entrichten. Wer was besser weiß, soll es bitte einfach editieren. Außerdem bin ich irgendwie nicht so der Wikistylekünstler. Vielleicht kann mir da ja noch jemand n bissel helfen. Danke und grüße Christoph signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Panoramio
Am 23.04.2009 01:56, Martin Koppenhoefer: Am 22. April 2009 22:00 schrieb Claudiusclaudiu...@gmx.de: Am 22.04.2009 16:55, Martin: Danke genau das wars was ich gesucht habe. :) Jetzt auch mit Flickr-Unterstützung. Muss man da was einstellen für Flickr? Die Bilder der letzten Mapping-Party (seit ca. 1,5 Wochen bei Flickr und werden dort auch auf der Karte angezeigt) konnte ich bei photosm nicht entdecken. Das Overlay in der Mitte oben (mit dem Logo Photosm) blitzt bei mir nur kurz auf, aber man kann nichts clicken und es verschwindet dann auch wieder, müsste ich dort was einstellen? Hm. ich hatte gestern nacht noch einen Quick Hack für Firefox 2 gemacht, der sich leider als Bumerang erwiesen hat. Hab das jetzt rückgängig gemacht. (Sorry, Michael) Flickr-Bilder sind am pinken Rahmen erkennbar, Panoramio am hellblauen. Die Layer können nach Klick oben über die OpenLayer-Controls an-/abgeschaltet werden. Leider begrenzt die Flickr-API Anfragen nach geolokalisierten Bildern, so dass ich nicht zuverlässig wirklich alle Bilder aus einem Bereich bekomme. Als Entschädigung gibt's links unter den Navigationselementen noch einen Locate me-Button :) Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin Deutschland update
Garry schrieb: This is a rough guide. From the cgpsmapper manual. 7 128 km/h 6 108 km/h 5 93 km/h 4 72 km/h 3 56 km/h 2 40 km/h 1 20 km/h 0 8 km/h (ferry) Ich nehme an das ist die anzunehmende Gescwindigkeit fürs routing und nicht für maxspeed? Ja. Wie werden den die Werte aus den OSM-Daten umgesetzt? highway=bridleway road_class=0 road_speed=0 highway=byway road_class=0 road_speed=0 highway=cycleway road_class=0 road_speed=1 highway=footway road_class=0 road_speed=0 highway=minor road_class=1 road_speed=2 highway=motorway road_class=4 road_speed=6 highway=motorway_link road_class=4 road_speed=3 highway=pedestrianroad_class=0 road_speed=0 highway=primary road_class=3 road_speed=4 highway=primary_link road_class=3 road_speed=3 highway=residential road_class=0 road_speed=2 highway=living_street road_class=0 road_speed=2 highway=secondary road_class=2 road_speed=3 highway=path road_class=0 road_speed=0 highway=service road_class=0 road_speed=1 highway=steps road_class=0 road_speed=0 highway=tertiary road_class=1 road_speed=3 highway=track road_class=0 road_speed=1 highway=trunk road_class=3 road_speed=5 highway=trunk_linkroad_class=3 road_speed=3 highway=unclassified road_class=1 road_speed=2 highway=unsurfacedroad_class=0 road_speed=1 route=ferry road_class=0 road_speed=0 Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Grillplatz/JOSM
Moin, an wen kann man sich wenden, wenn man in JOSM aus einem Picknickplatz (tourism=picnic_site) einen Grillplatz machen möchte und daher nicht nur nach fireplace=yes sondern auch nach barbecue_grill=yes (Grill vor Ort vorhanden) gefragt werden möchte? Danke Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grillplatz/JOSM
Am 23.04.2009 12:54, Falk Zscheile: an wen kann man sich wenden, wenn man in JOSM aus einem Picknickplatz (tourism=picnic_site) einen Grillplatz machen möchte und daher nicht nur nach fireplace=yes sondern auch nach barbecue_grill=yes (Grill vor Ort vorhanden) gefragt werden möchte? Was ist denn der Unterschied bei einem barbecue_grill? Gitter vor Ort? Aufhängevorrichtung? Links und rechts zwei Steinblöcke auf die man einen mitgebrachten Gitterrost legen könnte? Ansonsten könnte ich das Preset aktualisieren. Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Panoramio
Am 23. April 2009 13:53 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 23. April 2009 12:21 schrieb Claudius claudiu...@gmx.de: Hm. ich hatte gestern nacht noch einen Quick Hack für Firefox 2 gemacht, der sich leider als Bumerang erwiesen hat. Hab das jetzt rückgängig gemacht. (Sorry, Michael) ah OK, danke für die Info, jetzt funktioniert wieder alles, man kann auch die Layer sehen und auswählen. es gibt noch ein Problem: wenn ich panoramio deaktiviere und danach den Ausschnitt minimal verschiebe (~1 pixel), aktiviert es sich von selbst wieder und man bekommt trotzdem die Google-Bilder. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grillplatz/JOSM
Am 23. April 2009 13:32 schrieb Claudius claudiu...@gmx.de: Am 23.04.2009 12:54, Falk Zscheile: an wen kann man sich wenden, wenn man in JOSM aus einem Picknickplatz (tourism=picnic_site) einen Grillplatz machen möchte und daher nicht nur nach fireplace=yes sondern auch nach barbecue_grill=yes (Grill vor Ort vorhanden) gefragt werden möchte? Was ist denn der Unterschied bei einem barbecue_grill? Du meinst zu einer Feuerstelle? Gitter vor Ort? Aufhängevorrichtung? Links und rechts zwei Steinblöcke auf die man einen mitgebrachten Gitterrost legen könnte? Ich meine schon einen gemauerten, jedenfalls irgendwie fest installierten, Grill. Der Gitterrost sollte natürlich auch vorhanden sein, falls er nicht gerade geklaut wurde. Auf ein extra tag hierfür würde ich aber vorerst verzichten. Die Information ob ein Grill vor Ort vorhanden ist erspart unter Umständen viel Transportarbeit. Eine Feuerstelle ist für mich eher eine Einfassung innerhalb derer man Feuer machen kann. Weitere Annehmlichkeiten wie etwa Grill sind nicht vorhanden und müssen selbst mitgebracht werden. Vom Unterschied zwischen einem Lagerfeuer und einem Häufchen glühender Kohlen zum garen von Fleisch ganz abgesehen. Ansonsten könnte ich das Preset aktualisieren. Muss man dazu Entwickler sein oder kann das ggf. auch der interessierte Laie? Danke und Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte für ganz Deutschland
Am 23. April 2009 10:45 schrieb Stephan Wolff s.wo...@web.de: Es ging um eine zu hohe Punktdichte auf Wegen. Es gibt einige nahezu gerade Wege, die aus offenbar im Sekundentakt aufgezeichneten GPS-Datenpunkten bestehen. Eine mögliche Definition redundanter Punkte wäre: Wegpunkte, die keine Tags haben, einen Knickwinkel zwischen 170 und 190 Grad bilden, seit 14 Tagen unverändert sind und deren Entfernung den Weg um maximal 1m verändert. die kann man ja gern auch automatisch finden. Automatisch korrigieren finde ich trotzdem nicht gut, da es durchaus auch möglich ist, dass Daten, die diesen Kriterien entsprechen, trotzdem Sinn ergeben (z.B. aus guten Quellen importierte Gebäude). Wenn ich Wege finde, die gerade sind, aber Zwischenpunkte haben (ohne Tags), dann lösche ich diese Punkte von Hand. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grillplatz/JOSM
Am 23. April 2009 13:57 schrieb Falk Zscheile falk.zsche...@googlemail.com: Du meinst zu einer Feuerstelle? Gitter vor Ort? Aufhängevorrichtung? Links und rechts zwei Steinblöcke auf die man einen mitgebrachten Gitterrost legen könnte? Ich meine schon einen gemauerten, jedenfalls irgendwie fest installierten, Grill. Der Gitterrost sollte natürlich auch vorhanden sein, falls er nicht gerade geklaut wurde. Auf ein extra tag hierfür würde ich aber vorerst verzichten. Eine Feuerstelle ist für mich eher eine Einfassung innerhalb derer man Feuer machen kann. Weitere Annehmlichkeiten wie etwa Grill sind nicht vorhanden und müssen selbst mitgebracht werden. Vom Unterschied zwischen einem Lagerfeuer und einem Häufchen glühender Kohlen zum garen von Fleisch ganz abgesehen. ich sehe den Unterschied eigentlich nicht so recht. Eine Feuerstelle, wie ich sie kenne, ist genau so eine gemauerte Einfassung, wo man erst ein Feuer macht, welches nach einiger Zeit zu einem Häufchen glühender Kohlen wird, auf denen man dann sein Fleisch gart. Von daher sehe ich eher ein Zusatztag für einen Grillrost als sinnvoll an (wenn man das braucht - ich bin selbst von der Fleisch-in-Alufolie-garen-Fraktion). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grillplatz/JOSM
Falk Zscheile falk.zsche...@googlemail.com wrote: an wen kann man sich wenden, wenn man in JOSM aus einem Picknickplatz (tourism=picnic_site) einen Grillplatz machen möchte und daher nicht nur nach fireplace=yes sondern auch nach barbecue_grill=yes (Grill vor Ort vorhanden) gefragt werden möchte? Was hält Dich davon ab den tag einfach so zu vergeben? In den Presets gibta das nicht, weil der tag meines Wissens noch nie irgendwo zur Diskussion stand. Gruss Sven -- If we want hardware to work to its full potential, we need to claim to be a recent version of Windows. (Matthew Garrett) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin Deutschland update
2009/4/23 Chris-Hein Lunkhusen chris66...@gmx.de: 2 40 km/h highway=living_street road_class=0 road_speed=2 ;-) Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin Deutschland update
Chris-Hein Lunkhusen chris66...@gmx.de wrote: highway=track road_class=0 road_speed=1 Das sollte man IMO bei tracktype grade 4 und 5 auf 0 setzen statt auf 1. Sven -- If you continue running Windows, your system may become unstable. (Windows 95 BSOD) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grillplatz/JOSM
Am 23. April 2009 14:14 schrieb Sven Geggus li...@fuchsschwanzdomain.de: Falk Zscheile falk.zsche...@googlemail.com wrote: an wen kann man sich wenden, wenn man in JOSM aus einem Picknickplatz (tourism=picnic_site) einen Grillplatz machen möchte und daher nicht nur nach fireplace=yes sondern auch nach barbecue_grill=yes (Grill vor Ort vorhanden) gefragt werden möchte? Was hält Dich davon ab den tag einfach so zu vergeben? In den Presets gibta das nicht, weil der tag meines Wissens noch nie irgendwo zur Diskussion stand. Ok, das leuchtet ein. Ich kann auch noch abwarten, ob sich ein Bedürfnis für solch ein tag noch bei anderen entwickelt. Die Grillsaison geht ja gerade erst los. Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkarte für ganz Deutschland
Johann H. Addicks addi...@gmx.net wrote: Vielleicht lässt sich die gelegentliche Briefkastensuche verschmerzen gegenüber eines grundsätzlich gestörten Weit-Routings. Ehrlich gesagt möchte ich beim mappen keine Karte auf dem Garmin haben, beid er der Briefkasten auf der falschen seite ist, denn dann muss ich mir einen vermeintlichen Fehler aufschreiben, den es dann beim nacharbeiten am heimischen Rechner gar nicht gibt. Ich habe jedenfalls wenig Lust beim mappen eine andere Karte in den Garmin zu spielen als für die Navigation. Sven -- This APT has Super Cow Powers. (apt-get --help on debian woody) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grillplatz/JOSM
Am 23. April 2009 14:06 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 23. April 2009 13:57 schrieb Falk Zscheile falk.zsche...@googlemail.com: Du meinst zu einer Feuerstelle? Gitter vor Ort? Aufhängevorrichtung? Links und rechts zwei Steinblöcke auf die man einen mitgebrachten Gitterrost legen könnte? Ich meine schon einen gemauerten, jedenfalls irgendwie fest installierten, Grill. Der Gitterrost sollte natürlich auch vorhanden sein, falls er nicht gerade geklaut wurde. Auf ein extra tag hierfür würde ich aber vorerst verzichten. Eine Feuerstelle ist für mich eher eine Einfassung innerhalb derer man Feuer machen kann. Weitere Annehmlichkeiten wie etwa Grill sind nicht vorhanden und müssen selbst mitgebracht werden. Vom Unterschied zwischen einem Lagerfeuer und einem Häufchen glühender Kohlen zum garen von Fleisch ganz abgesehen. ich sehe den Unterschied eigentlich nicht so recht. Eine Feuerstelle, wie ich sie kenne, ist genau so eine gemauerte Einfassung, wo man erst ein Feuer macht, welches nach einiger Zeit zu einem Häufchen glühender Kohlen wird, auf denen man dann sein Fleisch gart. Von daher sehe ich eher ein Zusatztag für einen Grillrost als sinnvoll an (wenn man das braucht Oha, da scheint es doch erhebliche regionale Unterschiede zu geben. So ist beispielsweise an allen fest installierten Grillgelegenheiten (incl. Rost) die ich kenne das entfachen eines Feuers mittels Holz nicht gestattet bzw. nicht gern gesehen. Dort wo Lagerfeuer erlaubt sind finden sich neben besagter Grillgelegenheit oder ausschließlich entsprechende Feuerringe. Zusammengefasst liegt für Dich schon ein Grillplatz vor, wenn man dort Lagerfeuer machen kann, um an diesem seine Nahrung zu garen. Für mich hingegen ist ein Grillplatz ein fest gemauerter Grill. Eine Feuerstelle impliziert für mich, dass ich meinen Grill selber dort hin schaffen muss, wenn ich Steaks essen will und mich nicht nur an den Flammen des Feuers erfreuen. - ich bin selbst von der Fleisch-in-Alufolie-garen-Fraktion). Diese Möglichkeit ist mir in meinem bisherigen Leben noch nicht begegnet. Das kannte ich bisher nur für Gemüse. Aber das wird, obwohl hoch interessant, leider Off-Topic. Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grillplatz/JOSM
Am 23. April 2009 14:31 schrieb Falk Zscheile falk.zsche...@googlemail.com: Oha, da scheint es doch erhebliche regionale Unterschiede zu geben. So ist beispielsweise an allen fest installierten Grillgelegenheiten (incl. Rost) die ich kenne das entfachen eines Feuers mittels Holz nicht gestattet bzw. nicht gern gesehen. Dort wo Lagerfeuer erlaubt sind finden sich neben besagter Grillgelegenheit oder ausschließlich entsprechende Feuerringe. viele der Stellen, die ich in Erinnerung habe, sind nur per Fuß oder Fahrrad erreichbar, da wirst Du kaum jemanden finden, der seinen Grill oder Grillkohle kilometerweit schleppt, wenn er dann am Ort der Verheißung sowieso eine Feuerstelle vorfindet ;-) Das kann aber gut sein, dass es hier regional stark unterschiedliche Gegeben- und Gepflogenheiten gibt. Ich bezog mich auf die Region Schönbuch / Schwäbische Alb / Donau / (Schwarzwald). Dort sind Feuerstellen (legale) eigentlich immer Natursteinummauert, ohne eine Einfassung darf man (denke ich) überhaupt kein Feuer machen. OT: Fleisch gründlich mit Alufolie umwickeln (ca. 3-4 Schichten) und direkt in die Glut legen, mehrmals wenden, ca. 15 Minuten garen, schmeckt hervorragend ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grillplatz/JOSM
Falk Zscheile schrieb: Ok, das leuchtet ein. Ich kann auch noch abwarten, ob sich ein Bedürfnis für solch ein tag noch bei anderen entwickelt. Die Grillsaison geht ja gerade erst los. Ja, und auch die Biergartensaison. (amenity=biergarten wird ja auch noch nicht gerendert). ;-) Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] living_street + maxspeed 7
Rolf Bode-Meyer schrieb: Am 23. April 2009 00:32 schrieb Garry garr...@gmx.de: Stimmt nicht ganz - Durchfahrt verboten mit einem _Zusatzschild das ein ballspielendes Kind symbolisiert gilt als Spielstrasse - maxspeed = 0 da jeglicher Verkehr verboten Ist das dann nicht eigentlich gleichbedeutend mit highway=footway? Aber ich denke es wird doch eher mit highway=residential, access=no, foot=yes getagt, oder? Nein, die Spielstrasse kann ja immer noch als Brandschutzzone(also Einsatzfahrzeugen) oder für Baufahrzeuge befahrbar sein die mit Sonderrechten ausgestattet werden... Bei footway würde ich da ehr mit physikalischen Hindernissen (zu schmalen Wegen) rechnen Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grillplatz/JOSM
Falk Zscheile schrieb: Ich meine schon einen gemauerten, jedenfalls irgendwie fest installierten, Grill. Der Gitterrost sollte natürlich auch vorhanden sein, falls er nicht gerade geklaut wurde. Auf ein extra tag hierfür würde ich aber vorerst verzichten. Die Information ob ein Grill vor Ort vorhanden ist erspart unter Umständen viel Transportarbeit. Du willst Dich dafür wirklich auf OSM Informationen verlassen? Du wirst Dir ganz schön den Zorn Deiner Mitgriller auf Dich ziehen und bei Ihnen OSM in Verruf bringen wenn der getaggte Rost nicht vorhanden bzw. nicht benutzbar ist... Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin Deutschland update
Martin Koppenhoefer schrieb: highway=track road_class=0 road_speed=1 Das sollte man IMO bei tracktype grade 4 und 5 auf 0 setzen statt auf 1. Sven bei living_street auch (s. mein Spampost weiter oben). Da steht bei 0 in Klammer aber ferry dahinter - sollte man vorher prüfen ob über diese Strassen noch geroutet wird wenn man Fähren vom Routing ausschliesst - sonst können manche Ziele nicht mehr oder sehr viel schlechter erreicht werden... Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grillplatz/JOSM
Am 23. April 2009 15:01 schrieb Garry garr...@gmx.de: Falk Zscheile schrieb: Ich meine schon einen gemauerten, jedenfalls irgendwie fest installierten, Grill. Der Gitterrost sollte natürlich auch vorhanden sein, falls er nicht gerade geklaut wurde. Auf ein extra tag hierfür würde ich aber vorerst verzichten. Die Information ob ein Grill vor Ort vorhanden ist erspart unter Umständen viel Transportarbeit. Du willst Dich dafür wirklich auf OSM Informationen verlassen? Du wirst Dir ganz schön den Zorn Deiner Mitgriller auf Dich ziehen und bei Ihnen OSM in Verruf bringen wenn der getaggte Rost nicht vorhanden bzw. nicht benutzbar ist... das kannst Du immer sagen. Wie gut man sich auf OSM verlassen kann, zeigt sich beim Benutzen der Karte. Es geht hier aber doch darum, ob man es überhaupt erfassen will, nicht, wie gut es dann auch erfasst und aktualisiert wird. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] out of copyright im Wiki
Ein gewisser Head hat auf dieser Seite: http://wiki.openstreetmap.org/wiki/Out-Of-Copyright verschiedene als freie Quellen angegebene Karten durchgestrichen mit den Hinweis, dass keine Angaben zu den Autoren vorlägen (alle Dokumente selbst älter als 70 Jahre), darunter auch Amtlicher Plan der Landeshauptstadt Stuttgart. Ist es bei solchen Werken nicht so, dass die Veröffentlichung gilt? Die Autoren sind doch evtl. gar nicht angegeben bei amtlichen Plänen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin Deutschland update
Am 23. April 2009 15:07 schrieb Garry garr...@gmx.de: bei living_street auch (s. mein Spampost weiter oben). Da steht bei 0 in Klammer aber ferry dahinter - sollte man vorher prüfen ob über diese Strassen noch geroutet wird wenn man Fähren vom Routing ausschliesst - sonst können manche Ziele nicht mehr oder sehr viel schlechter erreicht werden... ja, auch sind bisher keine Werte für Fahrradfahrer bekannt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] tourism attraction
Hallo zusammen, JOSM zeigt mir bei tourism attraction auch einen Weg immer als Fläche an. Laut Wiki ist das auch richtig so, was aber mache ich, wenn eine Sommerrodelbahn auch für Touristen interessant ist? Statt dem ganzen Weg einfach einen Punkt nur als tourism attraction markieren? Andere Vorschläge oder Ideen? Gruß Kai -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] out of copyright im Wiki
Martin Koppenhoefer schrieb: verschiedene als freie Quellen angegebene Karten durchgestrichen mit den Hinweis, dass keine Angaben zu den Autoren vorlägen (alle Dokumente selbst älter als 70 Jahre), darunter auch Amtlicher Plan der Landeshauptstadt Stuttgart. Ist es bei solchen Werken nicht so, dass die Veröffentlichung gilt? Die Autoren sind doch evtl. gar nicht angegeben bei amtlichen Plänen. Vor 1995 = altes Recht: 70 Jahre nach dem Tod des Urhebers Wenn der Kartograph den amtliche Plan im Jahr 1933 verfasst hat, aber noch bis 1960 gelebt hat, ist das Ding noch bis 2030 geschützt. Wobei man hier natürlich noch aufpassen muss, ob dies im Rahmen der Rechtsnachfolge und der Landesvermessung nicht noch stärker gewichtet wird. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin Deutschland update
Garry garr...@gmx.de wrote: Da steht bei 0 in Klammer aber ferry dahinter - sollte man vorher prüfen ob über diese Strassen noch geroutet wird wenn man Fähren vom Routing ausschliesst Also der default style (resources/styles/default/lines) verwendet das bei folgenden Wegen: bridleway,byway,footway,pedestrian,path,steps und ferry Für Fahrradfahrer hat das aber auch noch ganz andere implikationen: Man kann offensichtlich nur etwa 3 Klassen von Wegen unterscheiden (0-8,8-20 und 20 km/h) OK für die ganz sportlichen vielleicht noch Klasse 3 :) Das ist IMO leider zu grob :( Trotzdem wäre Klasse 0 für schlechtere tracks (grade3-grade5) sicher der bessere Wert als das derzeitige Klasse 1 für alle tracks. Aber schon hier sieht man, dass man gerne feinere Geschwindigkeitsbereiche alleine für Tracks hätte. Bei Fußgängern wirds dann noch enger, da kommt eigentlich nur Klasse 0 in Frage, das ist aber weniger schlimm, weil die übliche Schrittgeschwindigkeit ja normalerweise in Klasse 0 liegt. Gruss Sven -- The source code is not comprehensible (found in bug section of man 8 telnetd on Redhat Linux) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin Deutschland update
Martin Koppenhoefer dieterdre...@gmail.com wrote: ja, auch sind bisher keine Werte für Fahrradfahrer bekannt. Was meinst Du damit? Sven -- All bugs added by David S. Miller da...@redhat.com Linux Kernel boot message from /usr/src/linux/net/8021q/vlan.c /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ersatz fuer Namefinder
marcus.wolsc...@googlemail.com schrieb: http://travelingsales.svn.sourceforge.net/viewvc/travelingsales/trunk/libosm/src/org/openstreetmap/osm/data/searching/advancedAddressDB/ Wie sonst sollte ich eine Adress-Suche machen. Mal gucken, ob ich das zu PostGIS übersetzen kann. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grillplatz/JOSM
Martin Koppenhoefer schrieb: Am 23. April 2009 15:01 schrieb Garry garr...@gmx.de: Falk Zscheile schrieb: Ich meine schon einen gemauerten, jedenfalls irgendwie fest installierten, Grill. Der Gitterrost sollte natürlich auch vorhanden sein, falls er nicht gerade geklaut wurde. Auf ein extra tag hierfür würde ich aber vorerst verzichten. Die Information ob ein Grill vor Ort vorhanden ist erspart unter Umständen viel Transportarbeit. Du willst Dich dafür wirklich auf OSM Informationen verlassen? Du wirst Dir ganz schön den Zorn Deiner Mitgriller auf Dich ziehen und bei Ihnen OSM in Verruf bringen wenn der getaggte Rost nicht vorhanden bzw. nicht benutzbar ist... das kannst Du immer sagen. Wie gut man sich auf OSM verlassen kann, zeigt sich beim Benutzen der Karte. Es geht hier aber doch darum, ob man es überhaupt erfassen will, nicht, wie gut es dann auch erfasst und aktualisiert wird. Es ging mir hierbei weniger um die Frage des Erfassen als vielmehr um seinen letzten Satz mit der Transportarbeit... Wenn eine Strasse von jetzt auf sofort gesperrt wird gibt es in den meisten Fällen einen alternativen Weg der kaum ein paar Minuten kostet, in ganz seltenen Fällen mal im Stundenbereich. d.h. ich komme hier auch mit nicht ganz aktuellen Daten noch brauchbar ans Ziel. Will ich mir aber sparen einen Grill mitzuschleppen dann bin ich auf eine hochaktuelle Information angewiesen die mir OSM nicht geben kann. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Garminkarte tracktypes/surface
Hi, gibt es eine Garminkarte, die tracktype bzw. surface-tags beim generieren beachtet bzw. anzeigt? Wäre fürs Radfahren extrem praktisch. Meine Computerteddykarte (ohne typfile) zeigt aktuell leider keine Unterschiede zwischen Wegen mit verschieden tracktype-tags. Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tourism attraction
Hallo. Am Donnerstag 23 April 2009 16:51:43 schrieb elchtrei...@gmx.net: Laut Wiki ist das auch richtig so, was aber mache ich, wenn eine Sommerrodelbahn auch für Touristen interessant ist? Eine Sommerrodelbahn ist keine Attraktion. Auch ein Hotel oder ein Biergarten kann für Touristen attraktiv sein, ist deshalb aber kein tourism=attraction. Verwende einfach attraction=summer_toboggan und lebe damit, dass es momentan nicht so gerendert wird, wie du es vielleicht gerne hättest. Oder suche dir die Verantwortlichen für die Renderer und forciere eine Implementierung. Gruß, Bernd -- Fachbegriffe der Informatik (#287): Palestinänsertipper 1 Anschlag pro Minute. (Bodo Eggert) 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] Garminkarte tracktypes/surface
Hallo. Am Donnerstag 23 April 2009 17:33:42 schrieb Jonas Krückel: gibt es eine Garminkarte, die tracktype bzw. surface-tags beim generieren beachtet bzw. anzeigt? Wäre fürs Radfahren extrem praktisch. Als nicht-offroad-radler habe ich mir eine Karte gemacht, die tracktype=grade1 und tracktype=grade2 wie highway=service behandelt, grade3 wie einen Radweg und grade4 und grade5 wie einen Fußweg. Man sieht alleine dadurch dann schon einen gewissen Unterschied, den man natürlich mit einem Typfile noch stärker machen kann. Aber als ich gesehen habe, was man bei einem Typfile alles einstellen kann bzw. muss, hab ich da die Finger von gelassen. :) Gruß, Bernd -- Conny Ja, Nein, Vielleicht... Ich kann mich nicht entscheiden... mAZZe warte ich werf ne SD-Karte Bo_Wallace Willkommen in der Hitech-Generation - german-bash.org 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] Grillplatz/JOSM
Garry schrieb: Will ich mir aber sparen einen Grill mitzuschleppen dann bin ich auf eine hochaktuelle Information angewiesen die mir OSM nicht geben kann. Wo hast du denn Grillen gelernt? Ein guter Griller kann improvisieren. Informationen nicht zu erfassen, weil eine Fehlinformation einen potentiellen Schaden anrichten könnte ist irgendwie auch doof. Grüße Philipp ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
