[Talk-hr] area ili šume
Na koji način ucrtavate šume u OSM ako nema binga za to područje. -- Osnovni problem sa svijetom je u tome što su budale previše samouvjerene, a pametni stalno u dvojbi (Bertrad Ressell) ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
[talk-ph] Quirino Bridge, Banaoang, Santa, Ilocos Sur
Hi ! I again went to Vigan to stay for the night from Sta. Cruz last week, on my way I tried to route and noticed my Nuvi's directing me to use the old bridge, instead of the new one. http://www.openstreetmap.org/?lat=17.55973lon=120.46364zoom=16 on my way back it's still the same. Any idea why? guess it's because the old bridge is linked to the highway, the new one is a completely new way thus it's treated as a turn. also, from Vigan, I saw DPWH billboards decalring the portion of the road under repair as Manila North Road...the road's tagged as Narvacan - Vigan...street signs say it's National Highway and yet the DPWH billboard says Manila North Road. Hoping for a Bing update for Vigan and Ilocos Sur so we can have more complete road network there. Noticed also the missing Ilocos Sur- Abra Road near Narvacan on the map. -- --- I explore, therefore I blog. http://www.backpackingphilippines.com ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
[talk-ph] how do I tag watchtowers?
I found them in Ilocos Sur and La Union... bateria in san esteban and Luna, La Union didn't find them in Santa and Narvacan as advertised by Ilocos Sur gov't. :( temporarily tagged them as ruins using the drag-and-drop POIs of P2. I was thinking they're like castles or forts too how about lighthouses? :P -- --- I explore, therefore I blog. http://www.backpackingphilippines.com ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] Quirino Bridge, Banaoang, Santa, Ilocos Sur
I took a look at it and I noticed two things: 1. That old way which is supposed to be a bridge is not tagged as bridge. Maybe the routine algo regards a highway without a bridge as a faster route? 2. The new bridge has a motorroad:no tag while the old highway has only got the highway:trunk tag... maybe this has an effect on routing too? ed On Mon, Feb 21, 2011 at 4:33 PM, tutubi tut...@backpackingphilippines.comwrote: Hi ! I again went to Vigan to stay for the night from Sta. Cruz last week, on my way I tried to route and noticed my Nuvi's directing me to use the old bridge, instead of the new one. http://www.openstreetmap.org/?lat=17.55973lon=120.46364zoom=16 on my way back it's still the same. Any idea why? guess it's because the old bridge is linked to the highway, the new one is a completely new way thus it's treated as a turn. also, from Vigan, I saw DPWH billboards decalring the portion of the road under repair as Manila North Road...the road's tagged as Narvacan - Vigan...street signs say it's National Highway and yet the DPWH billboard says Manila North Road. Hoping for a Bing update for Vigan and Ilocos Sur so we can have more complete road network there. Noticed also the missing Ilocos Sur- Abra Road near Narvacan on the map. -- --- I explore, therefore I blog. http://www.backpackingphilippines.com ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- website administrator: - www.waypoints.ph - reeflife.eppgarcia.com PADI Divemaster #491048 ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
[talk-ph] JAXA ALOS imagery in Sierra Madre(was Re: Northern Luzon Imagery)
jgc and osm-ph mappers, I had a talk with JAXA Sentinel Asia guys and they said this is OK for public use and OSM tracing. Long term wish for me is to get direct access for future Sentinel Asia imagery. Keep your fingers crossed. On Wed, Nov 3, 2010 at 4:24 AM, Jean-Guilhem Cailton j...@arkemie.com wrote: Hi, I've georeferenced the JAXA ALOS AV2 jpeg image from 28/08/2008, that is publicly available from the Sentinel Asia emergency page linked from the UN-SPIDER link below. The area covered includes Divilican, Maconacon, Palanan, San Mariano... It can be previewed at: http://maps.nypl.org/relief/maps/preview/327 WMS link for JOSM: http://maps.nypl.org/relief/maps/wms/327?request=GetMapversion=1.1.1styles=format=image/pngsrs=epsg:4326exceptions=application/vnd.ogc.se_inimage; I do not know about its license. Maning has asked about it. In the meantime, use under your own responsibility. Best wishes, Jean-Guilhem Le 31/10/2010 07:22, maning sambale a écrit : Great! Anyway to have this data used in OSM editors? On 10/30/10, Jean-Guilhem Cailtonj...@arkemie.com wrote: Hi, UN-SPIDER now lists links to pre- and post-disaster (Juan/Megi typhoon) imagery of Northern Luzon: http://un-spider.org/page/3769/un-spider-spaceaid-space-based-information-tropical-cyclone-philippines Best wishes, Jean-Guilhem ___ 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: [talk-ph] how do I tag watchtowers?
Watchtowers can indeed be tagged as a ruin especially if its unused. We can always update to better tags when they exist in the future. As for lighthouses, see if you can pick something up here: http://wiki.openstreetmap.org/wiki/Lighthouse :-) On Mon, Feb 21, 2011 at 5:25 PM, tutubi tut...@backpackingphilippines.com wrote: I found them in Ilocos Sur and La Union... bateria in san esteban and Luna, La Union didn't find them in Santa and Narvacan as advertised by Ilocos Sur gov't. :( temporarily tagged them as ruins using the drag-and-drop POIs of P2. I was thinking they're like castles or forts too how about lighthouses? :P ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] maps for mountaineers/ outdoor lovers
Hi guys, We have decided that we will be having a separate outdoor recreation Garmin map for the hikers, mountaineers, mountain bikers, climbers, scuba divers, etc. This map will have contour lines for selected mountains as suggested. But unlike the main Garmin map, this will be updated only once a month since outdoor-related map features aren't edited/updated on the map as often as regular features like roads and POIs. But for those who want the latest, we will try to provide DIY tools so people can make their own custom Garmin maps. :-) On Mon, Feb 21, 2011 at 11:49 AM, tutubi tut...@backpackingphilippines.com wrote: +1 here just returned from trips to Ilocos Sur then Palawan... the monkey trail to the underground river is surprisingly present is OSM...nice...but i wasn't able to do it due to the usual lack of time. next time, i'll stay overnight in Sabang then trek rather than ride the boat...there's also Ugong rock and a new zipline (PH already becoming zipline crazy these days) --- I explore, therefore I blog. http://www.backpackingphilippines.com On Wed, Feb 16, 2011 at 10:04 PM, rem zamora pompy...@gmail.com wrote: hey! just thinking aloud here. i know we have our osm map. and we also have the 10m elevation contour map of the country. what if... we can consolidate the two. in maning's page (http://esambale.wikispaces.com/osmphil_garmin) there is already an osm map with contour. i havent checked it yet but the note says it is only metro manila map and it might get too cluttered. maybe, we can, put osm map for the whole country, and then put contour maps for special places/mountains like apo, kanlaon, pulag, mayon, et.al. im not sure how this can be implemented but maybe, just maybe there is a way to put contour maps (just for certain areas where it can be useful) with street maps from osm. this will eliminate me having to put two maps in my gpsr and enabling/disabling the mamp whic is needed/not needed. just a suggestion guys :) -- Rem Zamora 0916-55-11-407 ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [OSM-talk] Zero tolerance on imports
On 21 Feb 2011, at 07:09, yvecai wrote: IMO, 'imports' should be simply considered as datasources, not data. We lack tools to properly use this data. Having great tools like for imagery or GPS tracks in the various editors, maybe with a copy/paste feature to import data semi-manually would be very valuable. Then the 'import' job could just be to make the datasource easy to use to contributors. A server to centralize this datasets could help for visibility. Just to throw another anecdote out there – I did look at OSM many years ago. At the time I thought pt, they haven't even got my country on the map, let alone the little town I'm in, there's no way this'll get anywhere. A few years later I became a contributer because there was at least *some* data available that made the map useful – all I had to do was make it *more* useful. What I'm saying is that to me, no data was more of a turn off than some data. I'd suggest that instead of simply banning imports we need better tools for monitoring map quality and for showing users what our monitoring tool thinks of their area. If we tell new users hey, look at this bug list/source/date of origin overlay and see what you can add/change/delete/fix/... rather than simply presenting them with a map that may or may not be correct we might get more communities spring up. Essentially – tell people what they can do to help more clearly! Bob ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zero tolerance on imports
On Mon, Feb 21, 2011 at 2:29 PM, Thomas Davie tom.da...@gmail.com wrote: On 21 Feb 2011, at 07:09, yvecai wrote: IMO, 'imports' should be simply considered as datasources, not data. We lack tools to properly use this data. Having great tools like for imagery or GPS tracks in the various editors, maybe with a copy/paste feature to import data semi-manually would be very valuable. Then the 'import' job could just be to make the datasource easy to use to contributors. A server to centralize this datasets could help for visibility. Just to throw another anecdote out there – I did look at OSM many years ago. At the time I thought pt, they haven't even got my country on the map, let alone the little town I'm in, there's no way this'll get anywhere. A few years later I became a contributer because there was at least *some* data available that made the map useful – all I had to do was make it *more* useful. What I'm saying is that to me, no data was more of a turn off than some data. I'd suggest that instead of simply banning imports we need better tools for monitoring map quality and for showing users what our monitoring tool thinks of their area. If we tell new users hey, look at this bug list/source/date of origin overlay and see what you can add/change/delete/fix/... rather than simply presenting them with a map that may or may not be correct we might get more communities spring up. Essentially – tell people what they can do to help more clearly! Bob ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk India had very low coverage, and even now many areas lack coverage. whenever I go to a new area and try mapping it, I see lot of roads where there are no roads, infact there cannot be roads. Just some junk data imported. Its such a big mess, and often I have to do bulk deletes in remove areas. Infact sometimes I refrain, because I cannot tell the actual good data from junk data due to poor quality of satellite imagery. I would not advocate banning imports, but restricting them is a very good idea. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zero tolerance on imports
Hi. Why we discuss the goodness or badness of imports here with the argument of a complete map? Of course that argument is a good one - but if we look towards the future there will be a time - partly that's already in the present, where an area is mapped already with high detail by mappers not active any more. A new mapper, I believe, will not distinct between a (relatively good) import and years of manpower of ground-survey-mapping done in the previous two decades etc. We see a growing complexity in many tagging schemes, use of more and more sophisticated relations to model facts, and the discussion is only about ban imports. I agree, that imports should not lead to automatic or semi-automatic deletion of mappers work. I agree that imports have to be done carefully and with inclusion of the local community/s. But I think, we need mechanism to generally cope with the problem of existing data. We should put more effort in developing mechanisms to check, proofe and control existing data - not caring about import or simply old data. And finally we should work on reduction of the fear to make things wrong, as I think, that fear is growing with growing complexity of existant data. Banning import is a easy mantra to push out today as it avoids the bigger problem - but in future we will have the same problem with a bad connotation: in future the existent old mappers are human parts of the community, whose data probably has to be deleted whereas today we speak about technical data and single importers. These importers are often people who want to discuss and work on their imports. We should take this as a chance, not as an affront. regards Peter Am 21.02.2011 01:03, schrieb Felix Hartmann: On 21.02.2011 00:47, Daniel Sabo wrote: On Feb 20, 2011, at 3:16 PM, Felix Hartmann wrote: Couldn't agree more to it. Imports kill community and scare novices away. ... Most important things for OSM are good aerial photos coupled with large community. Worst are imports. The United States are so bad, I don't think OSM will ever become important there. The biggest thing to remember is that creating something is much more fun than correcting it. Imports make OSM a chore and no fun. As a former novice I completely disagree with you here. If the TIGER import hadn't happened I would have had zero interest in OSM, a vast empty map is not very inspiring. But really, no one here has hard data, whenever we say it destroys the community or it helps the community we're just throwing anecdotes at each other. What we need are better tools to build a community like Serge and Kevin are talking about, a dozen of us arguing on a mailing list about what 360k people really want isn't going to accomplish much. - Daniel Well we have no hard data, but evidence. Basically no users and editors in the US but loads in Europe. And loads of countries without imports flourishing as communities start to grow (like Slovakia, Czech Republic, Italy, Switzerland, Germany, Denmark) but less involvement in countries with imports. A vast empty map is no fun, but neither is a complete map. The worst is a seemingly complete map, with crap data (like plan.at data in Austria, that was in general off by around 20-100m). Just show me some neighboring countries where the one with imports some time ago (minimum 1 year) are doing better than neighboring countries/regions where no imports took place. I think imports are good for stuff we cannot easily record ourselves (like borders) - but no good for stuff we can get ourselves. And if you see tracing from aerial imagery as a chore, you're making a mistake. I think we should wait till local people do it. That way it gets better quality and is not much work for anyone. We should not strive to be complete, but offer more or different data than commercial map providers, because that's where we are good at. Striving to get a map with best use for carnavigation will not happen - our structure and means are really inferior here. Getting speciality maps noone can compete with large communities. ___ 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] Zero tolerance on imports
Hi! There is a considerable difference between an import into a mostly empty area - which is rather easy to achieve and mostly helpful - and an import into an already basically mapped area, which is hard to integrate and where existing data may be damaged. I believe that this should not happen, existing survey results should always have precendence over arial imagery or imported data. I believe that that a proper integration into existing data is hard to achieve, therefore it should not be done by beginners and it should be coordinated. There appears to be a common misconception that arial imagery and imported data is somehow better by default than the hand-drawn traces. Imports should not duplicate existing data and should not overwrite it. Badly executed imports can cripple the whole data in an area, replace current information by obsolete data and badly tagged imports can mess up whole tagging schemes by suddenly pushing the bad tagging as the majority use. To make a long story short, I believe that imports should be restricted or checked very tightly, except for first imports into a mostly empty area. When it comes to motivation, I was very happy to find that my chief area of interest was mostly empty, with just one major road and the motorway. This appealed to my sense as an explorer who could make a visible difference to the map. I happily spent a few weekends driving around and mapping all the secondary roads. When it became available, I appreciated arial imagery as a help to trace rivers and forests, which are hard to grasp otherwise, but stopped using it for roads and paths as in later surveys I found that the impression about the nature of the way derived from the picture was frequently wrong. A year later the map was mostly complete and it got boring. So I mapped the routes that I came along anyway, but I did no longer feel like going out of my way to map a neighboring area - it was already there, it was usable - why bother? So, personally, I believe that drawing the first roads on an empty map is much more fun and motivation than fixing mistakes in someone else's imported data. If the actuality, accuracy and quality of data is less than excellent, I would rather not import it at all. Motivated mappers can do better. bye Nop -- View this message in context: http://gis.638310.n2.nabble.com/Zero-tolerance-on-imports-tp6044534p6048406.html Sent from the General Discussion mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zero tolerance on imports
On 2/21/2011 5:44 AM, Peter Wendorff wrote: And finally we should work on reduction of the fear to make things wrong, as I think, that fear is growing with growing complexity of existant data. I consider myself fairly comfortable with the editing tools, but recently while attempting to enter data from survey obtained during travel, I was completely intimidated by the cluster of landuse + admin boundary + Communications infrastructure imports. I believe other tools place these on separate layers to avoid information overload. Next time I travel to that region again, I won't bother to survey; it's too much hassle to try to enter information in the tangled jumble of lines. I agree with those who have experienced mixed results after importing land use data - think 3 times before bringing it into your area, if at all. If you just want 'colored maps' for your region, it should be possible to combine these at render time. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zero tolerance on imports
I find this discussion very distasteful. I really like OSM's goals: a complete map of the Earth with more-or-less unlimited detail. But I don't understand why people think that this 500+ GIGABYTE map should be managed using 19th-century methods, i.e. manual labor. Waze is a much newer project than OSM. I don't really care for its data model, because I think it's much too limited in the amount of detail it's capable of capturing; OSM's model is much better IMO. BUT, Waze has captured traces of a much larger portion of the US than OSM has. Waze has both average and real-time speed data, whereas OSM has no provision for this whatsoever. At some point, OSM will reach a size -- either size of database, or number of users/contributors -- where it will become totally infeasible to manage with the tools we have (or rather, the tools we don't have). Those of you who think all automated or semi-automated data contributions are harmful to OSM are dooming this project to never be able to grow to become a leading source of mapping data. Do you think that when MapQuest started using OSM data to generate their maps, they performed all the necessary data transformations BY HAND? Last year, as part of a school project, I built a robot that will automatically create route relations for all the state highways in the US, being careful not to change or duplicate existing data. I haven't shared it with the community because a handful of users were so terrified of the prospect of automated edits, they insisted I do a large-scale trial run on a local copy of the database, and I haven't had the time to compile the results of those trial runs for review. The code would be in use already if not for a few people running around panicking about my devil-robot and its witchcraft. ... I don't even know how to end this e-mail. I'm so distressed by what I'm reading that it makes me want to just walk away from the whole project. -- Peter Budny \ Georgia Tech \ CS MS student \ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zero tolerance on imports
On Mon, Feb 21, 2011 at 10:03 AM, Peter Budny pet...@gatech.edu wrote: I find this discussion very distasteful. Peter, I'm sorry that you feel that way. Can you tell us what specifically you find distasteful? Is it the issue of automated edits or is there something else? I really like OSM's goals: a complete map of the Earth with more-or-less unlimited detail. But I don't understand why people think that this 500+ GIGABYTE map should be managed using 19th-century methods, i.e. manual labor. I the issue, which Wikipedia also faces, is that automated edits have a history of being problematic for the project. A very small number of people in the community are against all automated edits, but a majority of us are concerned that current automated edits have been so problematic as to turn away users and contributors. What we're discussing is how to get good automated edits while still allowing for 20th century methods of input, which include on the ground surveying. Waze is a much newer project than OSM. I don't really care for its data model, because I think it's much too limited in the amount of detail it's capable of capturing; OSM's model is much better IMO. Waze is proprietary. Is that right? BUT, Waze has captured traces of a much larger portion of the US than OSM has. Waze has both average and real-time speed data, whereas OSM has no provision for this whatsoever. That's true. I think some of this data could have come in through Transiki, but that project appears permanently on hold. Maybe y0u can be one of the people to revive it? At some point, OSM will reach a size -- either size of database, or number of users/contributors -- where it will become totally infeasible to manage with the tools we have (or rather, the tools we don't have). That's the issue we're discussing, and await your suggestions on ways to move forward with better tools. Those of you who think all automated or semi-automated data contributions are harmful to OSM are dooming this project to never be able to grow to become a leading source of mapping data. Peter, how does this mail help move the conversation for better tools forward? Do you think that when MapQuest started using OSM data to generate their maps, they performed all the necessary data transformations BY HAND? They didn't make many changes to OSM AFAICT. According to the talk they gave, they did indeed find many problems by hand, and had to make manual fixes. Last year, as part of a school project, I built a robot that will automatically create route relations for all the state highways in the US, being careful not to change or duplicate existing data. I haven't shared it with the community because a handful of users were so terrified of the prospect of automated edits, they insisted I do a large-scale trial run on a local copy of the database, and I haven't had the time to compile the results of those trial runs for review. The code would be in use already if not for a few people running around panicking about my devil-robot and its witchcraft. How could those user's concerns be addressed while still making things easy for you to do? - Serge ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zero tolerance on imports
Do you think that when MapQuest started using OSM data to generate their maps, they performed all the necessary data transformations BY HAND? Do you think that MapQuest would be using OSM data at all if it was no more accurate than the data they could automatically import themselves? Bob ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zero tolerance on imports
Hi, On 02/21/2011 04:03 PM, Peter Budny wrote: Those of you who think all automated or semi-automated data contributions are harmful to OSM are dooming this project to never be able to grow to become a leading source of mapping data. It is a common fallacy to believe that good map data could somehow, magically, be produced from computers that evaluate GPS tracks, camera recordings, or aerial imagery. If this were possible, then Google et al. would be 10 times as good at doing it as we are. The strength of OSM is the people on the ground. If you try to eliminate them from the equation you're left with an average quality, patchy map - and not the great map of the future that you seem to envisage. We want to make the map of the people, where everyone participates and feels responsible for his part in the work. This is not the Great Government Data Dump. Last year, as part of a school project, I built a robot that will automatically create route relations for all the state highways in the US, being careful not to change or duplicate existing data. [...] The code would be in use already if not for a few people running around panicking about my devil-robot and its witchcraft. Maybe you haven't been able to demonstrate the added value your mechanical edit would bring to the database? I mean, if it can be determined by a robot, then surely it would be redundant to have it in the data again? Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Mapping 'risky areas'
On 2/20/2011 8:48 PM, Hillsman, Edward wrote: My impression is that in most US cities, the places where a lot of POIs have been mapped from field work are in the older, gridded, more pedestrian-friendly parts of the area. This could be because there are more interesting things there, or that people who live there tend to be more likely to have personalities that lead them to get involved in OSM, but it also could be that it is just easier and safer to map there. I recall seeing a piece of research noting that areas with high crime rates tend not to get mapped in OSM, so these would be exceptions to the older-area trend, but support for the hypothesis that walkability matters a lot (high crime means not safe means no mapping on foot). I have seen this effect also - there are nearby areas that I will never survey because they are too risky. Even in a vehicle, I would not want to risk a breakdown. For the areas that are unfriendly to pedestrian and bicycle, I have used video from a vehicle. The results are minimally helpful because of the time it takes to locate features on the aerial map. I have just gotten a Contour Vidcam with a GPS - you can export the GPX trace with embedded video frame information. The track loads in JOSM, and I would like to write a plugin to allow selection of frames from the track, as well as highlight the track location based on the video location. I was going to take the simplest route however - the result might work only in Windows; I'm not sure there is a Java cross-platform media interface/control library. From a bit of experimentation, 2 of these vidcams would capture street signs on both sides of the street in a standard residential housing area in a single pass, or one vidcam mounted at an angle would require 2 passes. Urban canyons would still have too many GPS echoes, and would not be quite as useful. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapping 'risky areas'
Am 21.02.2011 17:10, schrieb Mike N: The track loads in JOSM, and I would like to write a plugin to allow selection of frames from the track, as well as highlight the track location based on the video location. I was going to take the simplest route however - the result might work only in Windows; I'm not sure there is a Java cross-platform media interface/control library. I''m working on this plugin. Unfortunatly there are still some issues so I would call it beta. What works for me fine is a second PC with VLC videoplayback to avoid context switchs between 2 apps. This works great with BING for orientation. risky areas sounds interesting. Might be a nice idea for the upcomming http://wiki.openstreetmap.org/wiki/How_do_you_map_in ;) cheers Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zero tolerance on imports
Frederik Ramm frede...@remote.org writes: Hi, On 02/21/2011 04:03 PM, Peter Budny wrote: Those of you who think all automated or semi-automated data contributions are harmful to OSM are dooming this project to never be able to grow to become a leading source of mapping data. It is a common fallacy to believe that good map data could somehow, magically, be produced from computers that evaluate GPS tracks, camera recordings, or aerial imagery. If this were possible, then Google et al. would be 10 times as good at doing it as we are. Google, like Waze, has both historic and real-time traffic data automatically generated by millions people with mobile phones. So in at least some ways, they ARE 10 times better than OSM. The strength of OSM is the people on the ground. If you try to eliminate them from the equation Whoa, who said anything about eliminating people? What I'm saying is that we should find ways to integrate human editors with automated or semi-automated tools, so that humans can delegate the tedious work to computers and spend more time doing things that can't be handled by computers. Last year, as part of a school project, I built a robot that will automatically create route relations for all the state highways in the US, being careful not to change or duplicate existing data. [...] The code would be in use already if not for a few people running around panicking about my devil-robot and its witchcraft. Maybe you haven't been able to demonstrate the added value your mechanical edit would bring to the database? The value is that http://wiki.openstreetmap.org/wiki/Kentucky#State_routes would show route relations for all 6000+ state routes in Kentucky, instead of 7... and then I could use the same code to finish the other 49 states in the US. And then with minor modifications, I could use the same code in other countries. As an analogy, we store OSM's source code in Subversion and Git, and let those tools compare files when we make a change. Could this be done by hand? Of course. But why would you want to? You would produce the same result (actually, you're more likely to make a mistake than the computer). Yes, sometimes the tools come upon situations they can't handle, and have to let a human intervene, but they relieve us of the tedious bits. Some people look at OSM and say, It needs more tools. Some people say, It needs less tools. Consider me firmly in the first camp. I mean, if it can be determined by a robot, then surely it would be redundant to have it in the data again? First, your reasoning is specious. Consider a shopping receipt: what's the added value to listing a subtotal and total, when these could be trivially computed by summing the items purchased and subtracting the amount paid? Second, the robot's contributions would not be perfect... but then again, neither are mine. I've never drive down Kentucky State Highway 483, so any edits I make to it are merely the best I can do given what's already in OSM. But if I see tiger:name_base=State Highway 483, I'm going to put it in a relation with the other ways that match it. A robot can do exactly the same thing, only a lot more efficiently than I can. And before you counter... no, I don't think it's pointless or wrong to edit a part of the map I've never been to. If I (or anyone else) ever DOES go there, it would be nice to have already improved the map as much as possible, rather than letting it remain a completely unedited jumble or void. -- Peter Budny \ Georgia Tech \ CS MS student \ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zero tolerance on imports
Peter, The point isn't whether or not your tool will create correct route relations but what the point of doing that would be. I can understand creating route relations for long distance cycling/hiking paths that people actually want to navigate and historic routes (Route 66 comes to mind as a non-American) but what is the point of creating a route relation for every highway? No-one gets up in the morning and decides to navigate State Highway 483 from one end to the other and even if they did a decent routing engine could create the route on the fly, so adding it to OSM is a waste of time and would just add pointless complexity to the data-set. Kevin On 21 February 2011 16:58, Peter Budny pet...@gatech.edu wrote: Frederik Ramm frede...@remote.org writes: Hi, On 02/21/2011 04:03 PM, Peter Budny wrote: Those of you who think all automated or semi-automated data contributions are harmful to OSM are dooming this project to never be able to grow to become a leading source of mapping data. It is a common fallacy to believe that good map data could somehow, magically, be produced from computers that evaluate GPS tracks, camera recordings, or aerial imagery. If this were possible, then Google et al. would be 10 times as good at doing it as we are. Google, like Waze, has both historic and real-time traffic data automatically generated by millions people with mobile phones. So in at least some ways, they ARE 10 times better than OSM. The strength of OSM is the people on the ground. If you try to eliminate them from the equation Whoa, who said anything about eliminating people? What I'm saying is that we should find ways to integrate human editors with automated or semi-automated tools, so that humans can delegate the tedious work to computers and spend more time doing things that can't be handled by computers. Last year, as part of a school project, I built a robot that will automatically create route relations for all the state highways in the US, being careful not to change or duplicate existing data. [...] The code would be in use already if not for a few people running around panicking about my devil-robot and its witchcraft. Maybe you haven't been able to demonstrate the added value your mechanical edit would bring to the database? The value is that http://wiki.openstreetmap.org/wiki/Kentucky#State_routes would show route relations for all 6000+ state routes in Kentucky, instead of 7... and then I could use the same code to finish the other 49 states in the US. And then with minor modifications, I could use the same code in other countries. As an analogy, we store OSM's source code in Subversion and Git, and let those tools compare files when we make a change. Could this be done by hand? Of course. But why would you want to? You would produce the same result (actually, you're more likely to make a mistake than the computer). Yes, sometimes the tools come upon situations they can't handle, and have to let a human intervene, but they relieve us of the tedious bits. Some people look at OSM and say, It needs more tools. Some people say, It needs less tools. Consider me firmly in the first camp. I mean, if it can be determined by a robot, then surely it would be redundant to have it in the data again? First, your reasoning is specious. Consider a shopping receipt: what's the added value to listing a subtotal and total, when these could be trivially computed by summing the items purchased and subtracting the amount paid? Second, the robot's contributions would not be perfect... but then again, neither are mine. I've never drive down Kentucky State Highway 483, so any edits I make to it are merely the best I can do given what's already in OSM. But if I see tiger:name_base=State Highway 483, I'm going to put it in a relation with the other ways that match it. A robot can do exactly the same thing, only a lot more efficiently than I can. And before you counter... no, I don't think it's pointless or wrong to edit a part of the map I've never been to. If I (or anyone else) ever DOES go there, it would be nice to have already improved the map as much as possible, rather than letting it remain a completely unedited jumble or void. -- Peter Budny \ Georgia Tech \ CS MS student \ ___ 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] Zero tolerance on imports
Kevin Peat wrote: The point isn't whether or not your tool will create correct route relations but what the point of doing that would be. I can understand creating route relations for long distance cycling/hiking paths that people actually want to navigate and historic routes (Route 66 comes to mind as a non-American) but what is the point of creating a route relation for every highway? Navigation, for starters : turn-by-turn indications are improved by being able to mention turn left on route 35. Besides, it is static geographic data which fits OpenStreetMap's basic purpose, so as long as it does not step on anyone's toes it is relevant even if there is only one user. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zero tolerance on imports
You don't need a route relation to do that just a ref tag. Kevin On 21 February 2011 17:40, Jean-Marc Liotier j...@liotier.org wrote: Navigation, for starters : turn-by-turn indications are improved by being able to mention turn left on route 35. Besides, it is static geographic data which fits OpenStreetMap's basic purpose, so as long as it does not step on anyone's toes it is relevant even if there is only one user. ___ 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] Zero tolerance on imports
On 02/21/2011 11:26 AM, Kevin Peat wrote: The point isn't whether or not your tool will create correct route relations but what the point of doing that would be. I can understand creating route relations for long distance cycling/hiking paths that people actually want to navigate and historic routes (Route 66 comes to mind as a non-American) but what is the point of creating a route relation for every highway? Getting highway shields to render, for one. No-one gets up in the morning and decides to navigate State Highway 483 from one end to the other and even if they did a decent routing engine could create the route on the fly, so adding it to OSM is a waste of time and would just add pointless complexity to the data-set. No one? Really? Pretty sure that some people do in fact do this sort of thing… —Alex Mauer “hawke” ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zero tolerance on imports
Okay, even if we accept that -- and many OSM mappers do not, which is why there are tens of thousands of route relations in the database -- who is going to add all those ref tags? You haven't addressed the original problem, which is that there is a lot of editing to be done, some of which is tedious and easily performed by computers. ~ Peter Budny Kevin Peat ke...@kevinpeat.com writes: You don't need a route relation to do that just a ref tag. Kevin On 21 February 2011 17:40, Jean-Marc Liotier j...@liotier.org wrote: Navigation, for starters : turn-by-turn indications are improved by being able to mention turn left on route 35. Besides, it is static geographic data which fits OpenStreetMap's basic purpose, so as long as it does not step on anyone's toes it is relevant even if there is only one user. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Peter Budny \ Georgia Tech \ CS MS student \ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zero tolerance on imports
2011/2/21 Kevin Peat ke...@kevinpeat.com: You don't need a route relation to do that just a ref tag. +1 you need the relation if there is more than one route using the same street (because ref=23;42 is ugly). The relation might also be convenient for mappers to download a longer and in great detail (split ways) mapped road. Cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zero tolerance on imports
Serge Wroclawski emac...@gmail.com writes: On Mon, Feb 21, 2011 at 10:03 AM, Peter Budny pet...@gatech.edu wrote: I find this discussion very distasteful. Peter, I'm sorry that you feel that way. Can you tell us what specifically you find distasteful? Is it the issue of automated edits or is there something else? Let me try to elaborate as concisely as possible. OSM right now has very little tools to support editing. Compare this to text processing, where we have diff, patch, CVS and Subversion, etc. The tools can't handle every case, but they do the tedious work and help support higher-level functionality. Wikipedia extended this to support crowd-sourced editing, and has support for, e.g. detecting a reverting vandalism. Right now OSM lacks tools like that. When a user like Josh Doe has a data source with hyper-accurate road centerlines, the only way to integrate that into OSM is manually. When someone else destroys some existing data, either accidentally or maliciously, we have to post to the newsgroups to get an admin to fix things manually. There is a whole realm of tools and techniques to support computerized mapping that are waiting to be developed. No doubt other groups like Google, Bing, and even MapQuest are already working on them. I really don't understand how certain individuals propose to manage a large database with many contributors WITHOUT the aid of tools to make the humans' jobs easier. I really like OSM's goals: a complete map of the Earth with more-or-less unlimited detail. But I don't understand why people think that this 500+ GIGABYTE map should be managed using 19th-century methods, i.e. manual labor. I the issue, which Wikipedia also faces, is that automated edits have a history of being problematic for the project. A very small number of people in the community are against all automated edits, but a majority of us are concerned that current automated edits have been so problematic as to turn away users and contributors. What we're discussing is how to get good automated edits while still allowing for 20th century methods of input, which include on the ground surveying. See above. I generally agree with this goal. Waze is a much newer project than OSM. I don't really care for its data model, because I think it's much too limited in the amount of detail it's capable of capturing; OSM's model is much better IMO. Waze is proprietary. Is that right? My point, as below, was that Waze is another crowd-sourced map which has much better tools and support for semi-automated editing than OSM does. What difference does the license make? BUT, Waze has captured traces of a much larger portion of the US than OSM has. Waze has both average and real-time speed data, whereas OSM has no provision for this whatsoever. -- Peter Budny \ Georgia Tech \ CS MS student \ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapping 'risky areas'
On 2/20/2011 8:48 PM, Hillsman, Edward wrote: My impression is that in most US cities, the places where a lot of POIs have been mapped from field work are in the older, gridded, more pedestrian-friendly parts of the area. This could be because there are more interesting things there, or that people who live there tend to be more likely to have personalities that lead them to get involved in OSM, but it also could be that it is just easier and safer to map there. I recall seeing a piece of research noting that areas with high crime rates tend not to get mapped in OSM, so these would be exceptions to the older-area trend, but support for the hypothesis that walkability matters a lot (high crime means not safe means no mapping on foot). This is an important problem to highlight, which has been backed up by quantitative analysis by Muki Hakley http://povesham.wordpress.com/2009/12/28/the-digital-divide-of-openstreetmap/ The typical approach has been technological mediation, as you're suggesting ... use satellite imagery or other technologies to safely get into such places. It works just ok in my opinion. OSM has always been about inviting people to make the maps of their own neighborhoods themselves. They're going to have the most interest and best knowledge. They're going to be comfortable in areas you may not be. What it takes is reaching out beyond our normal networks, and finding interested and willing partners in new communities. This was our approach to mapping slums in Nairobi with Map Kibera. No way I was going to be mapping Kibera! http://mapkibera.org/ The same is true in the US. The Atlanta Mapathon organized by Thea Clay included tougher neighborhoods of that city. http://wiki.openstreetmap.org/wiki/Atlanta_Citywide_Mapathon I'm starting to see opportunities in deprived areas throughout US cities from groups that want to map, especially with youth. Would be happy to discuss the possibilities more with anyone who's interested in making this happen. -Mikel___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapping 'risky areas'
On Mon, Feb 21, 2011 at 10:18 AM, Mikel Maron mikel_ma...@yahoo.com wrote: I'm starting to see opportunities in deprived areas throughout US cities from groups that want to map, especially with youth. Would be happy to discuss the possibilities more with anyone who's interested in making this happen. +1 - It would be a good thing to reach out to local neighborhood organizations and teach them about OSM, and know they would be receptive. For DC, it's a matter of organizational capacity for our local group but doing some outreach in less affluent neighborhoods here is definitely something on my to-do list. Cheers, Katie -Mikel ___ 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] Zero tolerance on imports
I believe imports can be great, but of course can be dangerous. Better tools are needed, and maybe someday I'll have the skills and know-how to help with them. There's one thing that hasn't explicitly been mentioned. Some say we don't want to import because it will demotivate people to start contributing in that area. I can understand that, however, if we _KNOW_ the data is good, and we're careful to maintain the contributions already in existence, I'd much rather import the entire road network for an area, and have interested contributors not just FIX the data, but actually improve OSM by adding additional tags, map nearby paths, add intersections, etc. It is a terrible waste of human effort to reproduce verified high-quality data that is available and properly licensed. Their time is much better spent adding value to the map by improving the tags, adding unmapped paths, etc. The big problem with imports now is the lack of good tools, though I'm not complaining because I know they take a lot of effort to design and create. Regards, -Josh On Mon, Feb 21, 2011 at 10:03 AM, Peter Budny pet...@gatech.edu wrote: I find this discussion very distasteful. I really like OSM's goals: a complete map of the Earth with more-or-less unlimited detail. But I don't understand why people think that this 500+ GIGABYTE map should be managed using 19th-century methods, i.e. manual labor. Waze is a much newer project than OSM. I don't really care for its data model, because I think it's much too limited in the amount of detail it's capable of capturing; OSM's model is much better IMO. BUT, Waze has captured traces of a much larger portion of the US than OSM has. Waze has both average and real-time speed data, whereas OSM has no provision for this whatsoever. At some point, OSM will reach a size -- either size of database, or number of users/contributors -- where it will become totally infeasible to manage with the tools we have (or rather, the tools we don't have). Those of you who think all automated or semi-automated data contributions are harmful to OSM are dooming this project to never be able to grow to become a leading source of mapping data. Do you think that when MapQuest started using OSM data to generate their maps, they performed all the necessary data transformations BY HAND? Last year, as part of a school project, I built a robot that will automatically create route relations for all the state highways in the US, being careful not to change or duplicate existing data. I haven't shared it with the community because a handful of users were so terrified of the prospect of automated edits, they insisted I do a large-scale trial run on a local copy of the database, and I haven't had the time to compile the results of those trial runs for review. The code would be in use already if not for a few people running around panicking about my devil-robot and its witchcraft. ... I don't even know how to end this e-mail. I'm so distressed by what I'm reading that it makes me want to just walk away from the whole project. -- Peter Budny \ Georgia Tech \ CS MS student \ ___ 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] Zero tolerance on imports
Peter Budny wrote: OSM right now has very little tools to support editing. Compare this to text processing [..] This thread certainly has something to do with advanced version control for geographic data. That said, a discussion that happened a few months ago here (http://www.mail-archive.com/talk@openstreetmap.org/msg33788.html) did not conclude positively about branching and merging being capable of solving the import management conundrum. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zero tolerance on imports
On 21/02/2011 18:03, Peter Budny wrote: Okay, even if we accept that -- and many OSM mappers do not, They've clearly not heard the posh woman inside my satnav then - she has no problems pronouncing name and ref information on roads (she can't pronounce Huthwaite, but that's another problem). The UK road numbering rules are different from the US in that one road can be part of more than one route (in the UK if routes A1234 and A2345 joined for a bit and then separated the joint bit would be labelled A1234 or A2345, but not both) so I guess that that's why you're keen to create lots of route relations. The problem is, changes like these are not actually getting unmapped stuff mapped or capturing extra detail. You haven't addressed the original problem, which is that there is a lot of editing to be done, some of which is tedious and easily performed by computers. Actually, I'm really not convinced that there's a lot of EDITING to be done. In some cases there is a bit of tidying (such as someone drew some roads that didn't quite join, whereas in the real world they do) but in most cases it's ADDING that's needed. There might be a lot of editing needs doing where crap has been imported, but that's a different issue. What there are are lots of blank spaces on the map. For example, I spent Sunday afternoon here: http://www.openstreetmap.org/?lat=52.7692lon=-0.6682zoom=13layers=M A couple of bits could count as editing but most of it was adding new stuff that (a) hadn't been added to OSM before and (b) isn't actually freely accessible anywhere else (or isn't recorded anywhere at all), and that you can only find out by Actually Going There. Unfortunately there's no Big Goverment Dataset that says that there's a stile here, or that Path X is blocked by a barbed wire fence, or that you have to climb over a wall to get to Y. As http://weait.com/content/how-well-can-you-map; says: A mapper on every block. That's what we want. Tell your friends. Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zero tolerance on imports
Peter, I have nothing against automated edits in general as long as they are useful, are tested properly and don't overwrite other people's efforts without agreement. As I mentioned earlier in this thread I think the difficulty in contacting contributors in an area makes that hard to do. I am not interested in contributing to Waze but I have skimmed their forums out of curiosity and they don't seem to have any answers to these problems as far as I can see. They may have traction in the US but the Waze map of the UK looks like it was drawn by a five year-old. In the case of Josh Doe's centreline data if he can't do it himself he should try to team up with someone who can produce a tool to compare the highway geometries in the two data-sets and take it from there. Maybe you could give him a hand with that or know someone who might help? Kevin On 21 February 2011 18:03, Peter Budny pet...@gatech.edu wrote: Okay, even if we accept that -- and many OSM mappers do not, which is why there are tens of thousands of route relations in the database -- who is going to add all those ref tags? You haven't addressed the original problem, which is that there is a lot of editing to be done, some of which is tedious and easily performed by computers. ~ Peter Budny Kevin Peat ke...@kevinpeat.com writes: You don't need a route relation to do that just a ref tag. Kevin On 21 February 2011 17:40, Jean-Marc Liotier j...@liotier.org wrote: Navigation, for starters : turn-by-turn indications are improved by being able to mention turn left on route 35. Besides, it is static geographic data which fits OpenStreetMap's basic purpose, so as long as it does not step on anyone's toes it is relevant even if there is only one user. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Peter Budny \ Georgia Tech \ CS MS student \ ___ 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] Zero tolerance on imports
Jean-Marc Liotier j...@liotier.org writes: Peter Budny wrote: OSM right now has very little tools to support editing. Compare this to text processing [..] This thread certainly has something to do with advanced version control for geographic data. That said, a discussion that happened a few months ago here (http://www.mail-archive.com/talk@openstreetmap.org/msg33788.html) did not conclude positively about branching and merging being capable of solving the import management conundrum. That's good to hear (I admit to not being on the lists much the last few months). I'm not surprised that people couldn't get behind a branch-merge system; it works well enough for source code and text, usually, but that doesn't mean it's perfect for an entirely different type of data. All that says to me, is that OSM should look at OTHER techniques for handling data. For instance, how might one merge three sets of data... let's say, TIGER has good coverage but bad alignment and bad name tags, another data set may have good centerlines but no tags, and a third may have good name tags but poor coverage. Surely there is a way to integrate all of these (and merge them with existing OSM data) other than to just open it all in JOSM and do it by hand? -- Peter Budny \ Georgia Tech \ CS MS student \ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zero tolerance on imports
SomeoneElse li...@mail.atownsend.org.uk writes: On 21/02/2011 18:03, Peter Budny wrote: Okay, even if we accept that -- and many OSM mappers do not, They've clearly not heard the posh woman inside my satnav then - she has no problems pronouncing name and ref information on roads (she can't pronounce Huthwaite, but that's another problem). The UK road numbering rules are different from the US in that one road can be part of more than one route (in the UK if routes A1234 and A2345 joined for a bit and then separated the joint bit would be labelled A1234 or A2345, but not both) so I guess that that's why you're keen to create lots of route relations. The problem is, changes like these are not actually getting unmapped stuff mapped or capturing extra detail. I really don't mind whether it's route relations or ref tags. The problem is that NEITHER is finished. To get to my house, I have to get on State Route 1966, then 1267. Neither of these are marked as such on the map, and I'm certainly not going to do it by hand when I could write a tool that will fix those AND all the rest of the U.S. at the same time. -- Peter Budny \ Georgia Tech \ CS MS student \ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] talk Digest, Vol 78, Issue 79
Date: Mon, 21 Feb 2011 10:18:24 -0800 (PST) From: Mikel Maron mikel_ma...@yahoo.com To: Mike N nice...@att.net, talk@openstreetmap.org Subject: Re: [OSM-talk] Mapping 'risky areas' Message-ID: 238196.90955...@web161608.mail.bf1.yahoo.com Content-Type: text/plain; charset=us-ascii On 2/21/2011 10:18:24 -0800 (PST), Mikel Maron mikel_ma...@yahoo.com wrote: and safer to map there. I recall seeing a piece of research noting that areas with high crime rates tend not to get mapped in OSM, so these would be exceptions to the older-area trend, but support for the hypothesis that walkability matters a lot (high crime means not safe means no mapping on foot). The typical approach has been technological mediation, as you're suggesting ... use satellite imagery or other technologies to safely get into such places. It works just ok in my opinion. OSM has always been about inviting people to make the maps of their own neighborhoods themselves. They're going to have the most interest and best knowledge. They're going to be comfortable in areas you may not be. What it takes is reaching out beyond our normal networks, and finding interested and willing partners in new communities. This was our approach to mapping slums in Nairobi with Map Kibera. No way I was going to be mapping Kibera! http://mapkibera.org/ The same is true in the US. The Atlanta Mapathon organized by Thea Clay included tougher neighborhoods of that city. http://wiki.openstreetmap.org/wiki/Atlanta_Citywide_Mapathon +1 But I'm starting to regret mentioning crime in my earlier post. The point I was trying to make focused on the physical environment, and the fact that a lot of suburbia in the US is not conducive to walking. In addition, its design and heavy levels of car traffic make some areas unsafe for walking. I think this makes suburbia harder to map than older, gridded areas. I've mapped in both. I live in a suburban setting (because it's close to where I work), but I much prefer to map in areas that are safer to walk around in. I've also managed imports of bus stops into several cities where almost none had been mapped (after trying to contact everyone who had mapped any of them). So I think technological mediation has value. But there are lots of things that don't show up on imagery or in public-domain files, and things that don't, such as stores, bicycle parking, and speed limits, contribute to quality of life. So my concern was about walkability and suburbia, not about crime. Ed Hillsman ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zero tolerance on imports
On 21.02.2011 19:18, Peter Budny wrote: Let me try to elaborate as concisely as possible. OSM right now has very little tools to support editing. Without imports, data creation is performed by the same community, and with the same tools, as the editing and maintenance that follow data creation. It is therefore likely that the speed and direction of the database's development will correspond to community growth and tool improvements, and will never be overwhelming. With imports, this isn't guaranteed. It is unfortunately very easy to move too fast or in the wrong direction with imports, because you are not using the same tools that you will have to use when you want to improve the data with local knowledge, or update it when reality changes. Manual edits are the most important class of contributions to OSM. But manual edits are performed with a different set of tools than imports, and by different people. So we need to make sure that our imports do not create data that cannot (due to amount or complexity) be handled easily by existing local communities with the available tools for manual editing. The best way to achieve this, IMO, is to only execute mass edits and imports in collaboration with a local community. This makes sure that there is a sufficiently developed community of mappers on the ground, allows them to evaluate the data's quality beforehand, and makes it likely that the data will be well integrated into the OSM database soon after the import. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zero tolerance on imports
Peter Budny wrote: I really don't mind whether it's route relations or ref tags. The problem is that NEITHER is finished. To get to my house, I have to get on State Route 1966, then 1267. Neither of these are marked as such on the map, and I'm certainly not going to do it by hand when I could write a tool that will fix those AND all the rest of the U.S. at the same time. The big problem with your proposal to auto-generate relations from the TIGER tags is that, while TIGER in many/most areas is pretty good for alignment and street names, it's pretty horrible for routings of numbered routes in built-up areas and with being up-to-date on route changes. I suggest going county-by-county through the official listings at http://transportation.ky.gov/planning/reports/SPRS_listings/SPRS_listings.asp and marking ref tags on each by hand (rather simple after downloading a xapi query into JOSM), with FIXME tags where the routing is unclear. Then you can auto-generate relations from the ref tags. (Just remember that some routes, I think those numbered 6000+, are not signed.) -- View this message in context: http://gis.638310.n2.nabble.com/Zero-tolerance-on-imports-tp6044534p6050032.html Sent from the General Discussion mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] talk Digest, Vol 78, Issue 79
Hillsman, Edward wrote: But I'm starting to regret mentioning crime in my earlier post. The point I was trying to make focused on the physical environment, and the fact that a lot of suburbia in the US is not conducive to walking. In addition, its design and heavy levels of car traffic make some areas unsafe for walking. I think this makes suburbia harder to map than older, gridded areas. I've mapped in both. I live in a suburban setting (because it's close to where I work), but I much prefer to map in areas that are safer to walk around in. Unsafe driving is another type of crime, unfortunately one that is more acceptable in society. Hillsman, Edward wrote: I've also managed imports of bus stops into several cities where almost none had been mapped (after trying to contact everyone who had mapped any of them). Do you know if Florida law makes bus stop data public domain? I contacted Lynx (Orlando area) about importing their data but got no response. -- View this message in context: http://gis.638310.n2.nabble.com/Re-talk-Digest-Vol-78-Issue-79-tp6049733p6050046.html Sent from the General Discussion mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zero tolerance on imports
Tordanik wrote: The best way to achieve this, IMO, is to only execute mass edits and imports in collaboration with a local community. This makes sure that there is a sufficiently developed community of mappers on the ground, allows them to evaluate the data's quality beforehand, and makes it likely that the data will be well integrated into the OSM database soon after the import. Would you say the same about mapping in an area you're in on vacation? Or is it OK to dump incomplete data on an area with no local community as long as it's not an import? -- View this message in context: http://gis.638310.n2.nabble.com/Zero-tolerance-on-imports-tp6044534p6050056.html Sent from the General Discussion mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zero tolerance on imports
Nathan Edgars II nerou...@gmail.com writes: Peter Budny wrote: I really don't mind whether it's route relations or ref tags. The problem is that NEITHER is finished. To get to my house, I have to get on State Route 1966, then 1267. Neither of these are marked as such on the map, and I'm certainly not going to do it by hand when I could write a tool that will fix those AND all the rest of the U.S. at the same time. The big problem with your proposal to auto-generate relations from the TIGER tags is that, while TIGER in many/most areas is pretty good for alignment and street names, it's pretty horrible for routings of numbered routes in built-up areas and with being up-to-date on route changes. I suggest going county-by-county through the official listings at http://transportation.ky.gov/planning/reports/SPRS_listings/SPRS_listings.asp and marking ref tags on each by hand (rather simple after downloading a xapi query into JOSM), with FIXME tags where the routing is unclear. Then you can auto-generate relations from the ref tags. (Just remember that some routes, I think those numbered 6000+, are not signed.) That's hardly the only problem with it. There are lots of roads that are single-carriageway when they should be dual-carriageway, or vice verse. Not all dual-carriageway ways are marked oneway=yes. And yes, TIGER doesn't always have the route on the correct roads (although I would argue it's probably a minority of the cases). The thing is, whether the work is done by humans or robots, how are you going to know if it's right? There are a couple tools for it, and personally I would consider it easier to have the robot do all the roads, then I compare them to the documents you linked and correct the ones that are wrong. If it's correct, it would probably be a lot less effort to verify that than to create the route relation in the first place. But anyway... how do you know if the data is right? OSM doesn't have many tools for assisting humans in much of anything, whether it's creating new data, or augmenting data with new data sources or with information gleaned from examining metadata, or verifying data to make sure it's actually accurate. If automated edits are problematic, it's not because the robot apocalypse is coming. It's because automated edits are hacked together due to a lack of tools and support in OSM for doing anything other than manual editing. This isn't a problem with automated edits; it's a problem with OSM. -- Peter Budny \ Georgia Tech \ CS MS student \ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zero tolerance on imports
On 21.02.2011 21:43, Nathan Edgars II wrote: Tordanik wrote: The best way to achieve this, IMO, is to only execute mass edits and imports in collaboration with a local community. This makes sure that there is a sufficiently developed community of mappers on the ground, allows them to evaluate the data's quality beforehand, and makes it likely that the data will be well integrated into the OSM database soon after the import. Would you say the same about mapping in an area you're in on vacation? Or is it OK to dump incomplete data on an area with no local community as long as it's not an import? The potential negative effects of manual edits by a foreign mapper are nowhere close to those of imports. That's because ... a) ... a visitor will use similar tools as future local mappers. Imports are, in many ways, different from manual mapping. b) ... the amount of data that a human will collect during the short timespan of a vacation will usually not be beyond a future local community's maintenance capability. Imports are able to generate a lot more data than that. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zero tolerance on imports
On Mon, Feb 21, 2011 at 3:58 PM, Peter Budny pet...@gatech.edu wrote: The thing is, whether the work is done by humans or robots, how are you going to know if it's right? By going to it and checking. But anyway... how do you know if the data is right? OSM doesn't have many tools for assisting humans in much of anything, whether it's creating new data, or augmenting data with new data sources or with information gleaned from examining metadata, or verifying data to make sure it's actually accurate. That's because the assumption of OSM is that data is entered by ground surveying and therefore things like This road has N lanes is assumed to be true. If automated edits are problematic, it's not because the robot apocalypse is coming. It's because automated edits are hacked together due to a lack of tools and support in OSM for doing anything other than manual editing. This isn't a problem with automated edits; it's a problem with OSM. Peter, you've done an excellent job of identifying problems with OSM. Do you have any suggestions on how to resolve these issues? - Serge ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zero tolerance on imports
Serge Wroclawski emac...@gmail.com writes: On Mon, Feb 21, 2011 at 3:58 PM, Peter Budny pet...@gatech.edu wrote: If automated edits are problematic, it's not because the robot apocalypse is coming. It's because automated edits are hacked together due to a lack of tools and support in OSM for doing anything other than manual editing. This isn't a problem with automated edits; it's a problem with OSM. Peter, you've done an excellent job of identifying problems with OSM. Do you have any suggestions on how to resolve these issues? I would be naive to think that I have all the answers, or even some of them. It's a lot easier to point out problems than to solve them. However, you were kind enough to ask, so let me try to do some brainstorming: One big issue is that there's no way to combine two disparate sets of data any way but manually. Suppose TIGER 2015 data comes out and has centimeter-accurate centerlines, but still has all the typos and other nasty things that come with TIGER data. It would be great to use the centerlines but keep OSM's edited data for everything else. Or suppose I somehow get a database of every McDonald's location in the world, complete with addresses, phone numbers, etc. Rather than asking editors to pore over the whole map manually, it would be better if there were some kind of merge toolkit that can select portions of multiple data sets and combine them intelligently, automating the process when there are no conflicts (like a CVS merge). Of course the process needs to be guided by humans, but they shouldn't have to select or trace every single road. Here's another issue that ought to be much easier to solve, but hasn't been: the relation analyzer. http://ra.osmsurround.org/analyze.jsp?relationId=36947 That particular relation follows the correct practice of using role=(blank)/forward/backward, but even this isn't recognized by the analyzer. What it ought to show is just two chunks: from point A to B, and from point B to A. With the current display, how is one supposed to figure out if relation is completed or not? What about GPS tracks... how does one deal with those? The only interface I know is to click on GPS Traces from the slippy map, but that just gives me a list, and shows every trace in the whole world. I only want to see traces for the region I'm looking at, like show me every GPS track within 100m of this highway. I see there's a wiki page on change monitoring, but it doesn't look like there's anything very sophisticated. Perusing the history when there are so many edits that are -180 to 180 is a big turn-off. If mappers are supposed to watch their hometown for changes, shouldn't they be given tools to do that with? Like I said, this is just brainstorming. I'm sure other users also have ideas for tools that would make the editing process a lot less tedious, without even touching on the topic of automated edits. Tools like these can benefit everyone (unlike a discussion on how to tag lumber yards or hotdog carts or whatever the question du jour is). -- Peter Budny \ Georgia Tech \ CS MS student \ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zero tolerance on imports
I prefer this idea: mapnik etc could render only objects with version 2 or higher. Not only does that block out imports, but now we're at the point of completing various areas, it will make people go back and check them. matt amosBut they will just go and make tiny changes to increment the version without checking/matt amos yea yeah On 2/19/2011 5:04 PM, Andrew Errington wrote: On Sun, 20 Feb 2011 09:40:03 Frederik Ramm wrote: Finally, all these warnings must sound hollow to someone who lives in a place where 90% of data around him is imported. You will have a hard time telling him that imports are bad. I live in a place where 90% of the data is imported. Imports are bad. It's bad because I discover errors and start to think 'How many more errors must there be?'. It's mainly bad for two reasons. Firstly, the data is old, and there has been a significant road-building program going on here for a while. Secondly, things don't join up because the import processing didn't process road junctions properly, so routing doesn't work (until mappers go around and join them up). IMHO imports should exist as 'ghost objects' or 'pencil lines'. They should never render on Mapnik etc. and never be used for routing, but a mapper with local knowledge should be able to verify the objects and change them to a real object (i.e. 'ink them in'). Of course, if we had one million mappers here they could all take a quick look at their local area and fix the mistakes in a couple of days... Best wishes, Andrew ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Tools for a better tomorrow
I think there's been a useful discussion in the other thread for ideas which might help the project move forward, and so I'm going to lay them out and hopefully we'll have a more focused discussion. Idea 1: Better collaboration, especially regarding changes people make. This is something that several people expressed as an issue. They want to be able to discuss changesets better, and be able to refer to changesets in changesets. I have some ideas on communication which I hope to announce in a few weeks. As for changes in changeset, I think that could be solved with a new changeset tag refers_to or child_of, and the value would be the original changeset. Idea 2: An Import Layer The idea didn't come up this way, but one of the topics of discussion at a recent Wikipedia event I attended was the importance of Wikipedia Commons. Where Wikipedia is a secondary source, Wikipedia Commons allows users to upload primary sources for access. In the OSM context, the idea was for us to have an upload function like we do for GPX, but that would support import data, such as shapefile, KML, etc. This data could be used by users working on data. Idea 3: Better import testing If people are interested, I talked about this idea a while back, of a testing framework for imports and bots. This can include maps, but also (I think) should include seeing some sort of changeset of proposed changes, and allow users to comment on the process and output, before it hits the main database. Idea 4: Better comparison tools. A common concern by those wanting to do imports is we lack good comparison tools. Are there other things folks think we need or could be doing better? - Serge ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tools for a better tomorrow
I think you have to accept that many imports come through JOSM, the incident that initiated this thread wasn't an import problem as such just an incorrect selection and hitting the delete key too quickly in JOSM. Given the turn over of new people collaboration will always be a problem especially as many people map from aerial or satellite images. Not every one is interested in spending time over a beer or coffee before going out mapping. There is a problem with some older data in regard to incorrect street names. I found more than a hundred in my local city. Unfortunately they are difficult to confirm unless you are on the ground and damage the credibility of OSM. Moving to OdBL may get rid of some of the older work which maybe more prone to this sort of error. There is a great danger that OSM organisation as it is today will become an interesting piece of history. In the computer world things move very quickly and yesterday's darling is irrelevant today. A map based on importing the road network that includes correct street names and addresses using OSM tools with added POIs based on street addresses if they find the right imports would tend to be favored by many map users. We need better tools for validating tags. Give something the wrong tag and it doesn't ever appear in a render. Cheerio John On 21 February 2011 19:49, Serge Wroclawski emac...@gmail.com wrote: I think there's been a useful discussion in the other thread for ideas which might help the project move forward, and so I'm going to lay them out and hopefully we'll have a more focused discussion. Idea 1: Better collaboration, especially regarding changes people make. This is something that several people expressed as an issue. They want to be able to discuss changesets better, and be able to refer to changesets in changesets. I have some ideas on communication which I hope to announce in a few weeks. As for changes in changeset, I think that could be solved with a new changeset tag refers_to or child_of, and the value would be the original changeset. Idea 2: An Import Layer The idea didn't come up this way, but one of the topics of discussion at a recent Wikipedia event I attended was the importance of Wikipedia Commons. Where Wikipedia is a secondary source, Wikipedia Commons allows users to upload primary sources for access. In the OSM context, the idea was for us to have an upload function like we do for GPX, but that would support import data, such as shapefile, KML, etc. This data could be used by users working on data. Idea 3: Better import testing If people are interested, I talked about this idea a while back, of a testing framework for imports and bots. This can include maps, but also (I think) should include seeing some sort of changeset of proposed changes, and allow users to comment on the process and output, before it hits the main database. Idea 4: Better comparison tools. A common concern by those wanting to do imports is we lack good comparison tools. Are there other things folks think we need or could be doing better? - Serge ___ 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] Zero tolerance on imports
Peter Budny schrieb: The thing is, whether the work is done by humans or robots, how are you going to know if it's right? Now here's the actual argument why automated imports are often a bad thing: A lot of data is being added to the database *without being checked by anyone* for its quality. You might have seen the Example of plan.at in Austria in this thread, we had and have significant problems with the data imported from there because some of it is very bad quality and has been automatically connected with ways from existing surveyed and checked data, so often you can't even easily delete the wrong data again without doing harm. The most important reason why we need actual people to do work on the data is because they can check the quality by e.g. going there themselves, looking at multiple satellite images, etc. - of course including one of the most important items where OSM wins against a lot of other map material: local knowledge of the editors. Robert Kaiser ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zero tolerance on imports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 2011-02-21 16:03, Peter Budny skrev: it's capable of capturing; OSM's model is much better IMO. BUT, Waze has captured traces of a much larger portion of the US than OSM has. Waze has both average and real-time speed data, whereas OSM has no provision for this whatsoever. In sweden Waze have pickes over all up a much smaller part, and have much more error, extra parallel roads. Waze is a really usefull tool, i would love them to co-operate with OSM, Those of you who think all automated or semi-automated data contributions are harmful to OSM are dooming this project to never be able to grow to become a leading source of mapping data. The bigger the data base, the less useful automates imports, or I'm i missing something? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1jXPcACgkQtbR3SXmySreH/wCeJlqqvDvRWusRV/01tc/GFdKA OeAAnjW51C+m6nPFgBCIRv+Yr3HGxCqF =jyFC -END PGP SIGNATURE- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk-nl] Fwd: OpenStreetMap Wiki e-mail
Beste allemaal, Ter info onderstaande aankondiging van een Local User Group template voor de wiki. Ik heb 'm in Amsterdam ingezet. Het ziet er niet helemaal top uit, maar de informatie wordt wel geaggregeerd op een fraaie kaart! http://wiki.openstreetmap.org/wiki/Amsterdam Martijn -- Forwarded message -- From: !i! dig...@arcor.de Date: Mon, Feb 21, 2011 at 8:58 AM Subject: OpenStreetMap Wiki e-mail To: Mvexel mve...@gmail.com Hi Martin, as you might know, the German division has a nice map of all local groups at www.openstreetmap.de. Inspired by this one, I created an international version and a simple bot collecting all together. So if you put this on the page of your local meeting wiki page: http://wiki.openstreetmap.org/wiki/Template:User_group then you will appear after while here: http://ikaria.informatik.uni-rostock.de/mm337/osm/usergroups/ Now it's on us to present others our local meetups. I would be glad, if you would notify your local mailinglists :) regards Matthias -- This e-mail was sent by !i! to Mvexel by the E-mail user function at OpenStreetMap Wiki. -- martijn van exel +++ m...@rtijn.org laziness - impatience - hubris http://schaaltreinen.nl/ twitter / skype: mvexel flickr: rhodes ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] foutje 503
Heren techneuten. Ik heb de stoute schoenen aangetrokken en mij gestort in het MappenMaken. Bij het gebruik van Wget om een kleine bbox op te halen krijg ik fout 503 op de xapi. Is er iets mee aan de hand? Of is het niet beschikbaar zijn van de service tijdelijk? alvast bedankt voor de hulp Groet Robert___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [talk-au] temp name change
On Mon, 21 Feb 2011 07:47:08 +1100 Jim Croft jim.cr...@gmail.com wrote: Apparently from Yorkeshire, All the world is queer save thee and me, and even thou art a little queer. -- Robert Owen, 1828 This is how my dad used to quote it. Jim Nov 26 03, 6:19 PM On Monday, February 21, 2011, Elizabeth Dodd ed...@billiau.net wrote: On Sun, 20 Feb 2011 22:21:49 +1100 Steve Bennett stevag...@gmail.com wrote: Just out of curiosity, am I the only normal person on this email list? Steve everyone's odd except thee and me and even then i'm worried about thee sorry i can't recall the exact words of the quote nor do i know the original source thanks Jim ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] temp name change
Being a Yorkshireman by birth, I claim the definitive version: Everybody's daft bar thee and me, and th'art half cracked ...is how it was said in my family. Cheers b On 21 February 2011 17:38, Elizabeth Dodd ed...@billiau.net wrote: On Mon, 21 Feb 2011 07:47:08 +1100 Jim Croft jim.cr...@gmail.com wrote: Apparently from Yorkeshire, All the world is queer save thee and me, and even thou art a little queer. -- Robert Owen, 1828 This is how my dad used to quote it. Jim Nov 26 03, 6:19 PM On Monday, February 21, 2011, Elizabeth Dodd ed...@billiau.net wrote: On Sun, 20 Feb 2011 22:21:49 +1100 Steve Bennett stevag...@gmail.com wrote: Just out of curiosity, am I the only normal person on this email list? Steve everyone's odd except thee and me and even then i'm worried about thee sorry i can't recall the exact words of the quote nor do i know the original source thanks Jim ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au -- Ben Last Development Manager nearmap.com ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[Talk-de] Ungemappte Straßen und Wasser im Vergleich zu Google
Hallo, ich habe etwas gespielt. Herausgekommen ist ein Web-Mashup mit dem sich die Abdeckung von OSM visuell gegen Google vergleichen lässt. Das kann zur Routenplanung dienen um die richtige Straße mit dem GPS zu fahren oder auch als Hinweis für Sesselmapper wo noch von den Luftbildern abgezeichnet werden kann. Beim Abzeichnen von Luftbildern unbedingt darauf achten, dass diese gegen GPS-Spuren abgeglichen werden, die Bilder haben oft einen Versatz. Falls ein RemoteControl fähiger Editor läuft wird ein Button angezeigt mit dem der sichtbare Ausschnitt direkt geöffnet werden kann. Die Grenzen der Bing Luftbilder können zusätzlich eingeblendet werden. Mehr als Z10 herauszoomen hatte ich nicht vorgesehen, lässt sich aber im aktuellen stable OpenLayers nicht einstellen. Zu weit hineinzoomen macht meist auch keinen Sinn, da die Straßen doch leicht unterschiedlich liegen. Schaut es euch einfach mal an: http://compare.osm-tools.org/ Viel Spaß beim Mappen, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geplante Straße vom Rendering ausschließen?
Andre Joost Andre+Joost at nurfuerspam.de writes: Nimm die Karte von openstreetmap.de (nicht .org) als Hintergund. Da werden nur fertige Straßen dargestellt. Ist halt nur etwas langsamer im Bildaufbau. Aber vielleicht kannst du mit Frederik ja einen Deal machen, dass er dir alle Tiles deiner Gegend einmalig zukommen lässt, und du die auf dem eigenen Server statt der richtigen Karte einbaust. Die Geschwindigkeit reicht für meine Zwecke. Dennoch werde ich Frederik anschreiben, bevor ich die Daten auf die Vereinskarte übernehme. Um davon Ausdrucke machen zu können, muss ich zudem eine eigene Export-Funktion programmieren. Den Ersteller des fraglichen Weges habe ich angeschrieben. Keine Ahnung ob ich Antwort bekomme. Solange nichtmal der Verlauf exakt feststeht, tendiere ich aber dazu, die Straße von highway=proposed auf proposed=highway umzutaggen, um so das Rendering auszutricksen. Sollte das jemand zurückändern, versuche ich auf jeden Fall meine Prozesse auf openstreetmap.de umzubauen. Bin auch gerne bereit einen kleinen Obolus dafür zu leisten. Ist ja schön und gut, dass man Karten selber rendern kann, aber der Aufwand mit SQL und was weiß ich noch alles ist enorm. Man sollte Mapnik so erweitern, dass er auf die (TR|X)API losgehen kann. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geplante Straße vom Rendering ausschließen?
Hallo, On 02/21/11 09:48, Manuel Reimer wrote: Ist ja schön und gut, dass man Karten selber rendern kann, aber der Aufwand mit SQL und was weiß ich noch alles ist enorm. Man sollte Mapnik so erweitern, dass er auf die (TR|X)API losgehen kann. Mapnik kann bereits direkt OSM-Files einlesen, ohne jede Datenbank. Das doofe daran ist, dass man dafuer die normalen Stylesheets nicht verwenden kann, weil die halt vom Vorhandensein bestimmter, von osm2pgsql erzeugter, Datenbanktabellen ausgehen. Man muss also seine eigenen Styles basteln. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geplante Straße bitte nicht rendern!
Moin, Ulf Lamping schrieb: Am 20.02.2011 22:38, schrieb Frederik Ramm: Das bedeutet, dass wir eine geplante Strasse auf *keinen* Fall als highway=secondary, proposed=yes taggen sollten, +1 Auf jeden Fall +1 und *eigentlich* nicht mal als highway=proposed, sondern (zum Beispiel) als proposal=highway. Hätte ich jetzt mit beidem kein Problem, das highway=proposed ist halt schon etwas länger im Umlauf und hat bereits eine gewisse Verbreitung. und bietet zudem mit highway=proposed proposed=motorway eine in meinen Augen in gewisser Weise bereits gewohnte Syntax der Detailierung. proposal=highway proposed=motorway lässt mich dagegen irgendwie befürchten, dass es aus Gewohnheit zu proposal=highway highway=motorway mutiert. ;-) Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geplante Straße bitte nicht rendern!
Am 21.02.2011 08:31, schrieb Frederik Ramm: Hallo, On 02/21/11 04:04, Garry wrote: In der Regel gibt es für die Varianten auch Bezeichnungen (Variante1, Variante2, Bergtrasse, Taltrasse...) Hier macht es vielleicht Sinn wenn es zahlreiche Varianten gibt diese bei den normalen Karten vom Rendern auszuschliessen und durch eine zusammengefasste Trasse zu ersetzen die das Vorhaben (hier ist eine Umgehung geplant deren Verlauf noch nicht festliegt) deutlich macht. Jetzt reden wir natuerlich vom Rendering und nicht mehr von den Daten in OSM - aber hier ist eine Umgehung geplant, deren Verlauf noch nicht festliegt ist doch eher was fuer eine Strassenkarte in kleinem Masstab als fuer die Standard-OSM-Karte, die wir im Web anbieten. Jein, wie wir mit verschiedenen Trassen-Varianten umgehen ist ja schon eine gute Frage. Es macht für OSM z.B. wohl keinen Sinn, mehrere mögliche Trassen einzutragen die sich nur im Detail unterscheiden. Eine Möglichkeit wäre nur die offizielle Variante (wenn es denn sowas gibt) oder nur wesentliche Alternativen (z.B. eine am Berg, eine im Tal) bei OSM einzutragen und dann zusätzlich die Anzahl der bekannten Varianten als Tag einzutragen. Natürlich muß sich der Renderer dann überlegen, laut welchen Kriterien er sowas darstellen will (oder halt eben auch nicht). Momentan haben wir aber einfach zu wenig etablierte (Tag-)Details als das der Renderer das überhaupt sinnvoll unterscheiden kann. Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ungemappte Straßen und Wasser im Vergleich zu Google
interessante auswertung, wenn ich sie interpretieren könnte. Ein paar erklärende Worte wären schon hilfreich. ausserdem läuft bei mir der maus-cursor amok, solande die karte offen ist. (ff 3.6 / ubuntu 10.10) gruss walter - 33,33% aller Statistiken beruhen auf kleinen Datenmengen. -- View this message in context: http://gis.638310.n2.nabble.com/Ungemappte-Stra-en-und-Wasser-im-Vergleich-zu-Google-tp6047888p6048322.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geplante Straße bitte nicht rendern!
Hallo! IMO gehören Straßenplanungen, die noch unsicher sind, nicht in OSM. Und die Tatsache, daß Varianten zur Diskussion stehen oder überhaupt, daß es Diskussion gibt, implizieren dieses noch unsicher. Wenn es eine politische Entscheidung gibt, die Finanzierung geklärt ist und vielleicht schon mit den Bauvorbereitungen begonnen wurde, dann von mir aus. Aber so Planspiele wie Trassenvarianten kann man bequem als Layer auf OSM machen, dazu braucht's keine Nodes in der OSM-DB. Servus, Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ungemappte Straßen und Wasser im Vergleich zu Google
Walter Nordmann writes: wenn ich sie interpretieren könnte. Ein paar erklärende Worte wären schon hilfreich. Du siehst auf der Karte die Straßen und Gewässer die bei Google auf der Karte sind aber nicht in OSM. OSM-Elemente werden ausgeblendet. Damit man sich ein wenig zurechtfindet sind noch Grenzen sichtbar. In Zoom 10 funktioniert es am Besten, weiter herauszoomen ist nicht unterstützt. ausserdem läuft bei mir der maus-cursor amok, solande die karte offen ist. (ff 3.6 / ubuntu 10.10) Komisches Problem. Wie hängt der Mauscursor mit einem Browser zusammen? Mit FF unter Windows sehe ich kein Problem. Viele Grüße, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ungemappte Straßen und Wasser im Vergleich zu Google
Hallo, wenn ich sie interpretieren könnte. Ein paar erklärende Worte wären schon hilfreich. Du siehst auf der Karte die Straßen und Gewässer die bei Google auf der Karte sind aber nicht in OSM. OSM-Elemente werden ausgeblendet. Hm, wenn ich mir so Köln oder Bonn anschaue, dann scheint diese Visualisierung nicht so zu funktionieren. Beispiel Köln: http://compare.osm-tools.org/?zoom=12lat=50.93938lon=6.99207layers=BTF Nach der Visualisierung existieren zum Beispiel weder die Kölner Ringe in der OSM-Karte noch diverse Rheinbrücken oder Autobahnen. Auch der Rhein sollte in den OSM-Daten nicht vorhanden sein. Natürlich sind dies alles Elemente, die es schon lange in der OSM-Datenbank gibt. Trotzdem: Eine schöne Idee! Vielleicht lassen sich ja noch Bugs entfernen. Gruß, Stephan -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ungemappte Straßen und Wasser im Vergleich zu Google
Hi, Am 21.02.2011 12:50, schrieb sb-lis...@gmx-topmail.de: Du siehst auf der Karte die Straßen und Gewässer die bei Google auf der Karte sind aber nicht in OSM. OSM-Elemente werden ausgeblendet. Also so ganz folge ich der Auswertung noch nicht. laut compare ist z.Bsp. die Autobahn nicht in OSM und die Gewässer hier in Eching bei Landshut auch nicht: http://compare.osm-tools.org/?zoom=13lat=48.49948lon=12.06011layers=BTF schaut man sich aber die OSM Karte an, sind diese 100% erfasst: http://www.openstreetmap.org/?lat=48.4991lon=12.0596zoom=13layers=M auch die LA 18 von Viecht Richtung Süden und die B11, usw. usw. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ungemappte Straßen und Wasser im Vergleich zu Google
Stephan Knauss wrote: ausserdem läuft bei mir der maus-cursor amok, solange die karte offen ist. (ff 3.6 / ubuntu 10.10) Komisches Problem. Wie hängt der Mauscursor mit einem Browser zusammen? Mit FF unter Windows sehe ich kein Problem. danke für die info. jetzt seh ich, was da abgeht. das maus-problem ist auch weg ... ... nachdem ich die ff-unter-ubuntu-spezifischen mausbatterien getauscht habe ;) sorry, unglückliches timing. gruss walter - 33,33% aller Statistiken beruhen auf kleinen Datenmengen. -- View this message in context: http://gis.638310.n2.nabble.com/Ungemappte-Stra-en-und-Wasser-im-Vergleich-zu-Google-tp6047888p6048496.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ungemappte Straßen und Wasser im Vergleich zu Google
sb-lis...@gmx-topmail.de writes: Hm, wenn ich mir so Köln oder Bonn anschaue, dann scheint diese Visualisierung nicht so zu funktionieren. Oh, da hat noch eine kleine Info gefehlt: Visualisierung nur für Südost-Asien. Für Europa ist es bei der guten Abdeckung in OSM nutzlos. In Asien fehlen teilweise noch die Major-Roads. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ungemappte Straßen und Wasser im Vergleich zu Google
Am 21.02.2011 13:35, schrieb Stephan Knauss: Oh, da hat noch eine kleine Info gefehlt: Visualisierung nur für Südost-Asien. kleine Info? Das war wohl die entscheidende Info die gefehlt hat ;) Jetzt ist ja alles klar... Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ungemappte Straßen und Wasser im Vergleich zu Google
Am 21.02.2011 13:35, schrieb Stephan Knauss: Oh, da hat noch eine kleine Info gefehlt: Visualisierung nur für Südost-Asien. Stimmt, da wir hier nicht die Thai-Liste sind ist diese Info nicht ganz unwesentlich. ;-) ... nachdem ich die ff-unter-ubuntu-spezifischen mausbatterien getauscht habe Ist der Grund warum mir kein Funk-Mäuschen ins Haus kommen. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ungemappte Straßen und Wasser im Vergleich zu Google
Martin Czarkowski wrote: kleine Info? Das war wohl die entscheidende Info die gefehlt hat ;) Jetzt ist ja alles klar... typisches oss-problem: der entwickler einer software ist so stolz auf sein kind, dass er bei der freude, dass es endlich laufen kann, solche kleinigkeiten einfach vergisst ;) gruss walter p.s. mir geht das manchmal auch so - und wenn ich an das thema dokumentation denke, wird es mir auch schlecht. musste schon mal meine eigenen scripte debuggen um zu sehen, was die eigentlich machen sollten. - 33,33% aller Statistiken beruhen auf kleinen Datenmengen. -- View this message in context: http://gis.638310.n2.nabble.com/Ungemappte-Stra-en-und-Wasser-im-Vergleich-zu-Google-tp6047888p6048569.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geplante Straße bitte nicht rendern!
Am 21. Februar 2011 03:53 schrieb Garry garr...@gmx.de: Natürlich sind Planungen ein Fakt und es ist völlig legitim diese mit den dafür vorgesehenen Tags in OSM zu erfassen, wobei hier zweifelfrei in der Detailierung noch Verbesserungsbedarf besteht, u.a.: -Vorplanung m.E. für OSM schon etwas weit gefächert, wenn man erst konkretere Planungen eintrüge wäre das m.E. auch kein Schaden - Raumordnung abgeschlossen - planfestgestellt - beauftragt, meint das Planung beauftragt oder Ausführung beauftragt? das hier sind m.E. schon highway=construction und keine Planungsphasen bezogen auf OSM (vermutlich wird aber in diesen Phasen parallel auch weiterhin geplant/gezeichnet), von daher Phasen der Ausführung (die man ruhig auch mit einem Subtag eintragen kann, wobei das schon eine Kartierung zeitnah am Baufortschritt erfordert). freigeschnitten sagt mir nichts, das könnte auch noch Planung sein. - freigeschnitten - Unterbau hergestellt - Oberbau hergestellt - Verschleissdecke aufgetragen - Markierung aufgetragen Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geplante Straße bitte nicht rendern!
Matthias Versen wrote: Ich habe verständnis dafür das man eine Straße in OSM einzeichnet wenn die Planung abgeschlossen ist und das Geld bewilligt ist aber doch nicht wenn noch an der Route rumgeschraubt wird und die Anwohner und dusseligen Bürgerinitiativen noch jahrelang dagegen klagen. Was ist daran dusselig, wenn sich die Bürger versuchen gegen das zu wehren, was die Politiker gegen ihren Willen zu beschließen versuchen? Schlimm genug, dass all diese Bemühungen viel zu oft umsonst sind. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geplante Straße vom Rendering ausschließen?
Frederik Ramm wrote: Mapnik kann bereits direkt OSM-Files einlesen, ohne jede Datenbank. Das doofe daran ist, dass man dafuer die normalen Stylesheets nicht verwenden kann, weil die halt vom Vorhandensein bestimmter, von osm2pgsql erzeugter, Datenbanktabellen ausgehen. Man muss also seine eigenen Styles basteln. ... und wenn ich dann nur gezielt einige wenige Tiles rendern will um den Rest mit den Original-Tiles zu füllen, dann müsste ich erstmal das offizielle Style komplett 1:1 übersetzen... Im Fall Vereinskarte für Heimatverein wäre es in meinem Fall tatsächlich die allerbeste Lösung, wenn ich die Daten von openstreetmap.de nutzen könnte. Ist deine From-Adresse replyfähig? Falls nein, dann antworte mir mal direkt. Wäre schön, wenn man sich über eine Nutzung der Tiles einigen könnte. Wie schon geschrieben wäre auch eine regelmäßige Spende an den Serverbetreiber kein Thema. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geplante Straße bitte nicht rendern!
Manuel Reimer wrote: Ich habe verständnis dafür das man eine Straße in OSM einzeichnet wenn die Planung abgeschlossen ist und das Geld bewilligt ist aber doch nicht wenn noch an der Route rumgeschraubt wird und die Anwohner und dusseligen Bürgerinitiativen noch jahrelang dagegen klagen. Was ist daran dusselig, wenn sich die Bürger versuchen gegen das zu wehren, was die Politiker gegen ihren Willen zu beschließen versuchen? Schlimm genug, dass all diese Bemühungen viel zu oft umsonst sind. Weil heute nichts mehr geplant werden kann ohne das sich eine BI bildet. Strom will jeder haben aber ein Windrad, ein Kohlekraftwerk, ein Stausee, ein Biomassekraftwerk will keiner vor der Tür haben und eine Stromtrasse wegen der dezentralen Windenergie schon garnicht. Fast jeder hat ein Auto aber keiner will Straßen haben. Am lustigsten ist es, wenn sich bei einer Straße z.b. 2 BIs bilden die jeweils eine andere Trasse wollen und sich dann gegenseitig bekämpfen (siehe A30). Im Notfall muss dann Feldhamsterverleih.de herhalten wenn man schon vor Gericht verloren hat. Aber klar, die Schuld kann man immer auf die Politiker schieben, ist immer am einfachsten. Das gehört jetzt aber eigentlich nicht hierhin, darüber diskutiere ich gerne per Mail weiter. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] JOSM: Kann man einen gemeinsamen Knotenpunkt mehrerer Wege nur für einen bestimmten Weg löschen?
Hallo In OSM begegnet man immer wieder verschiedenen, sich kreuzenden Wegen mit gemeinsamen Knotenpunkten. Nach einer genaueren Ausrichtung der Straßen anhand GPS und der Bing Luftbilder verlaufen manche Straßen nur mehr nebeneinander und kreuzen sich eigentlich nicht. Kann man in JOSM einen gemeinsamen Knotenpunkt mehrerer Wege nur für einen bestimmten Weg löschen? Also einen Weg von dem gemeinsamen Knotenpunkt ausschließen. Gruß Benedikt ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: Kann man einen gemeinsamen Knotenpunkt mehrerer Wege nur für einen bestimmten Weg löschen?
Am 21. Februar 2011 18:12 schrieb Benedikt Schwarz bew...@gmx.com: Hallo In OSM begegnet man immer wieder verschiedenen, sich kreuzenden Wegen mit gemeinsamen Knotenpunkten. Nach einer genaueren Ausrichtung der Straßen anhand GPS und der Bing Luftbilder verlaufen manche Straßen nur mehr nebeneinander und kreuzen sich eigentlich nicht. Kann man in JOSM einen gemeinsamen Knotenpunkt mehrerer Wege nur für einen bestimmten Weg löschen? Also einen Weg von dem gemeinsamen Knotenpunkt ausschließen. ja, dazu erst den Knoten und den entspr. Way selektieren (letzteres ist wichtig, weil sonst der komplette Knoten aufgelöst wird), dann mit g den Knoten ablösen (unglue), dann mit entf löschen (der Knoten ist noch selektiert). Wichtig wie beschrieben, auch einen Way auszuwählen, weil nur g den kompletten Knoten auflöst (schwer zu erkennen) und dann das Routing nicht mehr funktionieren würde. Falls das doch mal passiert ist, bzw. um sicher zu gehen, kann man auch nach dem Löschen den kompletten Knoten nochmal selektieren (mit dem Auswahlrechteck, nicht durch Anclicken) und versuchen, mit m (Merge=verschmelzen) die Einzelteile wieder zu verbinden. Das sollte, wenn man richtig vorgegangen ist, eine Fehlermeldung verursachen (weil nur ein Knoten und nicht mehrere ausgewählt sind). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: Kann man einen gemeinsamen Knotenpunkt mehrerer Wege nur für einen bestimmten Weg löschen?
Am 21.02.2011 18:20, schrieb M∡rtin Koppenhoefer: Am 21. Februar 2011 18:12 schrieb Benedikt Schwarz bew...@gmx.com: Hallo In OSM begegnet man immer wieder verschiedenen, sich kreuzenden Wegen mit gemeinsamen Knotenpunkten. Nach einer genaueren Ausrichtung der Straßen anhand GPS und der Bing Luftbilder verlaufen manche Straßen nur mehr nebeneinander und kreuzen sich eigentlich nicht. Kann man in JOSM einen gemeinsamen Knotenpunkt mehrerer Wege nur für einen bestimmten Weg löschen? Also einen Weg von dem gemeinsamen Knotenpunkt ausschließen. ja, dazu erst den Knoten und den entspr. Way selektieren (letzteres ist wichtig, weil sonst der komplette Knoten aufgelöst wird), dann mit g den Knoten ablösen (unglue), dann mit entf löschen (der Knoten ist noch selektiert). Wichtig wie beschrieben, auch einen Way auszuwählen, weil nur g den kompletten Knoten auflöst (schwer zu erkennen) und dann das Routing nicht mehr funktionieren würde. Falls das doch mal passiert ist, bzw. um sicher zu gehen, kann man auch nach dem Löschen den kompletten Knoten nochmal selektieren (mit dem Auswahlrechteck, nicht durch Anclicken) und versuchen, mit m (Merge=verschmelzen) die Einzelteile wieder zu verbinden. Das sollte, wenn man richtig vorgegangen ist, eine Fehlermeldung verursachen (weil nur ein Knoten und nicht mehrere ausgewählt sind). Danke für die Erklärung :) Gruß Benedikt ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ungemappte Straßen und Wasser im Vergleich zu Google
Am Montag, den 21.02.2011, 13:35 +0100 schrieb Stephan Knauss: sb-lis...@gmx-topmail.de writes: Hm, wenn ich mir so Köln oder Bonn anschaue, dann scheint diese Visualisierung nicht so zu funktionieren. Oh, da hat noch eine kleine Info gefehlt: Visualisierung nur für Südost-Asien. Für Europa ist es bei der guten Abdeckung in OSM nutzlos. In Asien fehlen teilweise noch die Major-Roads. Stephan Und ich habe mich schon gewundert warum die Karte auf Korea gezoomt ist und ausschließlich japanische Beschriftungen enthält. Bitte das nächste Mal den Titel eindeutig wählen um unnötige Verwirrungen zu vermeiden. Gruß, André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neuer Kartenstil auf openstreetmap.de
Am Dienstag, den 08.02.2011, 16:59 +0100 schrieb Henning Scholland: Da hast du natürlich auch wieder Recht. Ich dachte jetzt eher an die normalen Städte wie Prag, Warschau, Lissabon, Athen usw. Wobei die Namen aus der Nazi-Zeit egtl. nichts in OSM verloren haben. Zumindest nciht unter name:de. Wenn dann als historisches oder so. Aus der Nazizeit oder vor 1945? Viele der damaligen Namen sind auch heute noch geläufig in den jeweiligen Gegenden. Wer kann sich beispielsweise etwas unter Zelená Ruda vorstellen? Wenn ich jedoch Eisenstein sage ist jedem klar, was gemeint ist. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neuer Kartenstil auf openstreetmap.de
Am Dienstag, den 08.02.2011, 23:11 +0100 schrieb Johannes Huesing: Wikipedia scheint ein ähnliches Sprachempfinden zu haben wie ich, da heißen die Lemmata Mailand und Klaipeda. So würde ich es auf einer deutschsprachigen Karte erwarten. Da gibt es auch regionale Unterschiede, auf österreichischen Straßenschildern steht Preßburg, bei der Diskussion um Stuttgart 21 heißt es hingegen Bratislava. Was hieltet ihr denn davon den lateinisch transkribierten Ortsnamen normal zu setzen und den deutschen Namen kursiv darunter zu platzieren? Gruß, André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] javascript-freie Onlinekarte
Hallo, gibt es irgendwo eine Webseite mit einer OSM, die auch ohne Javascript funktioniert? Beste Grüße, Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] javascript-freie Onlinekarte
Am 21.02.2011 21:19, schrieb Simon Kokolakis: gibt es irgendwo eine Webseite mit einer OSM, die auch ohne Javascript funktioniert? Sondern? Java? Flash? Silverlight? Mit reinem HTML kannst Du halt nix zoomen und scrollen. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neuer Kartenstil auf openstreetmap.de
Am 21.02.2011 20:49, schrieb André Reichelt: Wer kann sich beispielsweise etwas unter Zelená Ruda vorstellen? Wenn ich jedoch Eisenstein sage ist jedem klar, was gemeint ist. wer oder was ist EIsenstein? Grüße aus der Eifel Steffen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] javascript-freie Onlinekarte
Hallo, Simon Kokolakis wrote: gibt es irgendwo eine Webseite mit einer OSM, die auch ohne Javascript funktioniert? http://tah.openstreetmap.org/Browse/ Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] javascript-freie Onlinekarte
Am Montag, den 21.02.2011, 21:39 +0100 schrieb Chris66: gibt es irgendwo eine Webseite mit einer OSM, die auch ohne Javascript funktioniert? Sondern? Java? Flash? Silverlight? Mit reinem HTML kannst Du halt nix zoomen und scrollen. Na doch, über Links. Wie z.b. auf: http://maps.google.de/m/local?q=berlin Ich habe auch schon Karten gesehen, bei denen man zum zoomen auf die einzelnen Kacheln klicken kann, oder auf seitliche Umrandungen zum scrollen. Beste Grüße, Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] javascript-freie Onlinekarte
Am 21.02.2011 21:19, schrieb Simon Kokolakis: gibt es irgendwo eine Webseite mit einer OSM, die auch ohne Javascript funktioniert? Hier: http://tah.openstreetmap.org/Browse/ Den Link bekommt man auch, wenn man mit deaktiviertem Javascript auf openstreetmap.org geht. Gruß, Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] javascript-freie Onlinekarte
Am 21.02.2011 21:39, schrieb Chris66: Am 21.02.2011 21:19, schrieb Simon Kokolakis: gibt es irgendwo eine Webseite mit einer OSM, die auch ohne Javascript funktioniert? Sondern? Java? Flash? Silverlight? Mit reinem HTML kannst Du halt nix zoomen und scrollen. Klar kann man; war vor Javascript durchaus üblich in sehr frühen Kartenanwendungen. Gibt dann eben am Rand der statischen Karte Flächen, um zu scrollen (Schritt links/rechts/oben/unten) und zwei Links zum zoomen (rein und raus). Nicht besonders schön, aber definitiv machbar. Eine Umsetzung mit OSM aktuell kenne ich aber nicht. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ungemappte Straßen und Wasser im Vergleich zu Google
On 21.02.2011 13:52, Walter Nordmann wrote: der entwickler einer software ist so stolz auf sein kind, dass er bei der freude, dass es endlich laufen kann, solche kleinigkeiten einfach vergisst ;) Ja, tut mir echt leid, dass es deswegen Verwirrung gab. Ich habe das mal direkt in der Karte in der Infobox mit dazugeschrieben, dass es nur für SEA funktioniert. Der Server hat nur begrenzt Rechenkapazität. Falls die Idee ankommt und so eine Karte nützlich ist lässt sich das bestimmt auch auf den Toolserver bringen. Für Europe wo quasi schon jede kleine Straße drin ist bringt die Karte in meinen Augen nicht so viel. Und wenn man dicht ranzoomt stören die kleinen Lageabweichungen beim Übermalen der Google-Daten. Aber für SEA, wo teilweise die großen Verbindungsstraßen fehlen fand ich das super. Ich denke wenn OSM mal eine gewisse Grundabdeckung hat wird es zum Selbstläufer. Momentan ist der normale Nutzer dort meist mit Google Daten oder Google Navigation besser dran. In Thailand gibt es vereinzelt Gebiete die in OSM deutlich besser sind, aber das ist eher die Ausnahme. Ich hoffe, dass der ein oder andere Luftbildmapper jetzt vielleicht die Verbindungsstraßen einmalt. Sollte ich den Rest der Welt ohne Abdeckung ausgrauen? Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ungemappte Straßen und Wasser im Vergleich zu Google
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 21.02.2011 22:29, schrieb Stephan Knauss: Ich habe das mal direkt in der Karte in der Infobox mit dazugeschrieben, dass es nur für SEA funktioniert. Das SEA konnte ich aber auch erst nach dem weiteren Lesen dieses Threads interpretieren. (Die Karte deckt nur das Meer ab?) Vielleicht solltest Du es besser ausschreiben. Sollte ich den Rest der Welt ohne Abdeckung ausgrauen? Wäre sicher sinnvoll. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk1i3p0ACgkQnMz9fgzDSqfX4gCeNGD2107VBlEOeacgvs9KhUB9 R00An10dAjvIqFgjSqR6CTLWjAEjwNn9 =KvPi -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ungemappte Straßen und Wasser im Vergleich zu Google
On 21.02.2011 22:52, Bodo Meissner wrote: Das SEA konnte ich aber auch erst nach dem weiteren Lesen dieses Threads interpretieren. (Die Karte deckt nur das Meer ab?) Vielleicht solltest Du es besser ausschreiben. Das nimmt so furchtbar viel Platz weg ;) Habe es jetzt mit kleinerer Schrift dazugeschrieben. Denke das ist immer noch lesbar. Sollte ich den Rest der Welt ohne Abdeckung ausgrauen? Wäre sicher sinnvoll. Ich verhindere jetzt, dass aus dem Bereich herausgescrollt wird. Zusammen mit dem Hinweis sollte das jetzt hoffentlich verständlich sein. Ich habe auch noch die Darstellung auf niedrigere Zoomlevel erweitert. Bis Zoom 7 kann man jetzt rauszoomen. Dabei sieht man gut, dass z.B. Thailand im Vergleich zu Vietnam gut gemapped ist, aber trotzdem noch an manchen Stellen kurze Straßenstücke fehlen. Leider oft an den Stellen an denen es nur Landsat Abdeckung gibt. Aber auch dort lassen sich große Straßen oft problemlos erkennen. Und vielleicht fährt ja auch jemand in Urlaub und nimmt seinen Datenlogger mit. Ich bin ganz zuversichtlich, dass sich die Lücken bald schließen. Viel Spaß, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neuer Kartenstil auf openstreetmap.de
Am 14.02.2011 11:09, schrieb Sven Geggus: Wolfgangwolfg...@ivkasogis.de wrote: Es wäre schön, wenn das width-Tag eine Auswirkung hätte, bei Gewässern wie bei Osmarender, möglichst auch bei Straßen Das kann Mapnik nicht! Das stimmt so nicht. In einem Mapnik-Style kann man durchaus Straßen und Flüsse in Abhängigkeit von width-Tag in verschiedenen (festen) Breiten malen. Eine Straße mit =3m Breite könnte schmal, eine mit mehr als 7m Breite weit und die übrigen normal gezeichnet werden. Eine stufenlose Breitendarstellung scheint mir als Mapnik-Style allerdings nicht möglich zu sein. Viele Grüße, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neuer Kartenstil auf openstreetmap.de
Hi, Stephan Wolff wrote: Eine stufenlose Breitendarstellung scheint mir als Mapnik-Style allerdings nicht möglich zu sein. Mapnik2 hat eine Expression Engine, damit wird das vermutlich gehen. Aber ehrlich gesagt gehe ich davon aus, dass sich der Nutzen in engen Grenzen haelt. Einerseits ist es schoen, wenn wir die Realitaet in unseren Daten moeglichst genau wiedergeben koennen. Andererseits darf man nicht dem Trugschluss verfallen, eine Karte wuerde um so besser, je mehr sie sich einem Luftbild annaehert - so ein bisschen Generalisierung ist schon ganz ok. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] Consigli per iniziare a mappare
Il 21/02/2011 1.08, marco monini ha scritto: A questo proposito un'ultima domanda (per ora) dove posso trovare coordinate delle linee di confine provinciali e comunali? Mi sembra che qualcuna sia sbagliata. I confini già presenti provengono dall'istat e sono un po' grossolani. Di solito si trovano più precisi sulla carta tecnica regionale, bisogna vedere se anche la toscana l'ha resa disponibile. Mi pare che qui [0] ci sia qualcosa a riguardo ciao Marco [0] http://wiki.openstreetmap.org/wiki/Toscana ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Consigli per iniziare a mappare
2011/2/21 Elena ``of Valhalla'' elena.valha...@gmail.com: On 2011-02-21 at 02:56:31 +0100, M∡rtin Koppenhoefer wrote: hm, non lo sò. Il primo per me sarebbe il cartello tondo blue con la bici e un cartello supplementare che dice libero per pedoni (forse non esiste in Italia). L'implicazione è leggermente diversa (significa che i pedoni devono stare più attenti alle bici rispetto ad un percorso misto). Per me quel caso sarebbe piu` highway=cycleway, foot=yes, non designated si, hai ragione usando path in italia si rischia confusione con i sentieri e in generale i percorsi non progettati non lo vedo, designated non esiste per i sentieri secondome. non progettato uso informal=yes. Non ha da fare con path. path in quel modo e` usato quasi solo dai tedeschi, afaik, gli altri considerano footway e cycleway sufficienti per le strade dedicate al traffico lento, e usano path per quello che rimane, ovvero sentieri e percorsi che non sono strade mi riferisco sulla documentazione e su diversi discussioni in lista tagging. Se guardi le regole di mapnik vedi che anche loro consideranno un path, foot=designated uguale come un highway=footway (e la stessa cosa anche per bicycle=designated e horse). ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-co] IMG garmin
Hola Maperos donde puedo descargar el .img para un garmin? alguna vez compilé un mapa para un garmin con baja memoria, pero no me acuerdo muy bien como hacerlo, alguien me puede dar luces de nuevo? un saludo Vladimir ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co
[Talk-co] Compila tu propio mapa .IMG para #GPS #Garmin http://bit.ly/imgDIY
2011/2/23 Vladimir Montealegre vladi...@parapentismo.com: Hola Maperos donde puedo descargar el .img para un garmin? alguna vez compilé un mapa para un garmin con baja memoria, pero no me acuerdo muy bien como hacerlo, alguien me puede dar luces de nuevo? Te invito a compilar tu propio img y distribuirlo, para eso es muy útil http://www.mkgmap.org.uk/ y puedes bajar el volcado de Colombia desde http://download.geofabrik.de/ Instrucciones mas detalladas en http://wiki.openstreetmap.org/wiki/Mkgmap salu2 un saludo Vladimir ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co -- Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx, .ppt, .pptx, .mdb, mdbx OpenOffice es libre: se puede copiar, modificar y redistribuir libremente. Gratis y totalmente legal. http://GaleNUx.com es el sistema de información para la salud --///-- Teléfono USA: (347) 688-4473 (Google voice) skype: llamarafredyrivera ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co
Re: [Talk-es] Carreteras
Al hilo de la conversación, he calibrado los mapas que de la Junta de Andalucía mencionados más arriba para usarlos con JOSM a través del plug-in PicLayer. Esto permite superponer el mapa y ver rápidamente si alguna carretera de la red provincial o autonómica no está mapeada y su referencia. Luego, puede mapearse con fidelidad usando PNOA. ¿Veis algún problema en hacer este uso de los mapas? Básicamente se trata de facilitar la consulta de los mapas de la Junta mientras de mapea sobre PNOA. Por otro lado, entiendo que esto mapas son una representación fiel de lo publicado en el BOJA y que forman parte del Catálogo de Carreteras de Andalucía. El artículo 17 de la Ley 8/2001, de Carreteras de Andalucía, define el Catálogo de Carreteras de Andalucía como el instrumento de carácter público que sirve para la identificación e inventario de las carreteras que constituyen la red de carreteras de Andalucía, adscribiéndolas a las distintas categorías de la red y clasificándolas conforme a lo dispuesto en el texto legislativo. El único proceso realizado a los mapas es un cambio de formato a png y la posterior calibración para PicLayer, que va en un archivo de texto aparte. Si lo veis bien os paso un enlace con todo el material. Saludos. El día 20 de febrero de 2011 21:11, Jaume Figueras jaume.figue...@masafi.cat escribió: Hola, para la GIV-6219 y la 6227 hay el catalogo de Gencat [1]. Además Gencat dispone de la base cartográfica de carreteras para su descarga [2]. Y antes que preguntéis el aviso legal dice que se debe contactar con el departamento en cuestión, cosa que hice como es mi obligación y aún espero respuesta, y supongo que la esperaré toda la vida Aunque si somos unos cuantos que les decimos que queremos importar quizá contesten Salut! Jaume. [1] http://bit.ly/gIYrFH [2] http://bit.ly/fCm4Y5 On 02/20/2011 04:34 PM, Juan Luis Rodriguez wrote: El 19 de febrero de 2011 20:43, Roberto Plà p...@aire.org mailto:p...@aire.org escribió: ¿Hay alguna fuente en la que se pueda consultar la topología (Principio fin y principales cruces) del sistema de carreteras del Estado o autonómicas. Aunque sea una descripcion escrita no grafica. Para solventar ducas sobre etiquetar una determinada via, como por ejemplo la GIV-6219 que va de Siurana a...¿Tonyà? ...¿A la GIV-6227? Aquí [1] tienes las de Andalucía. En concreto, en este PDF [2] está lo que preguntas. Un saludo, Juan Luis. [1] http://www.juntadeandalucia.es/obraspublicasyvivienda/portal-web/web/areas/transportes_infraestructuras/infraestructuras/texto/92023603-8a71-11df-9aa8-00163e67c14a [2] http://www.juntadeandalucia.es/obraspublicasyvivienda/estaticas/sites/consejeria/areas/transportes_infraestructuras/documentos/memoria_listado.pdf -- Juan Luis Rodríguez Ponce Área de Proyectos www.emergya.es http://www.emergya.es/ ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Jorge Juan ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Carreteras
Finalmente he pedido permiso expreso a la Consejería para usar los mapas aunque, viendo los permisos en la web general y a falta de información específica respecto de los mapas, el permiso para uso personal está garantizado. Por tanto, incluyo un enlace [1] los archivos de calibración y un script bash para generar los PNG, por si alguien quiere bajar los PDF por su cuenta y convertirlos. Las instrucciones serían: 1. Descargar el archivo .zip y descomprimirlo en alguna carpeta local. 2. Descargar los PDF de [2] y colocarlos en la carpeta PDF que se ha creado al descomprimir el zip. 3. Ejecutar desde un interfaz de comandos en la carpeta donde se encuentra el script map2png.sh: bash map2png.sh Esto último es para GNU/Linux u otro sistema donde esté disponible bash y convert (ImageMagic). 4. Esperar a que se generen los PNG. Saludos. [1] http://www.wuala.com/jjchico/Public/OSM [2] http://www.juntadeandalucia.es/obraspublicasyvivienda/portal-web/web/areas/transportes_infraestructuras/infraestructuras/texto/e83f6dd6-ee41-11df-b3d3-21796ae5a548 El día 21 de febrero de 2011 12:39, Jorge Juan jjch...@gmail.com escribió: Al hilo de la conversación, he calibrado los mapas que de la Junta de Andalucía mencionados más arriba para usarlos con JOSM a través del plug-in PicLayer. Esto permite superponer el mapa y ver rápidamente si alguna carretera de la red provincial o autonómica no está mapeada y su referencia. Luego, puede mapearse con fidelidad usando PNOA. ¿Veis algún problema en hacer este uso de los mapas? Básicamente se trata de facilitar la consulta de los mapas de la Junta mientras de mapea sobre PNOA. Por otro lado, entiendo que esto mapas son una representación fiel de lo publicado en el BOJA y que forman parte del Catálogo de Carreteras de Andalucía. El artículo 17 de la Ley 8/2001, de Carreteras de Andalucía, define el Catálogo de Carreteras de Andalucía como el instrumento de carácter público que sirve para la identificación e inventario de las carreteras que constituyen la red de carreteras de Andalucía, adscribiéndolas a las distintas categorías de la red y clasificándolas conforme a lo dispuesto en el texto legislativo. El único proceso realizado a los mapas es un cambio de formato a png y la posterior calibración para PicLayer, que va en un archivo de texto aparte. Si lo veis bien os paso un enlace con todo el material. Saludos. El día 20 de febrero de 2011 21:11, Jaume Figueras jaume.figue...@masafi.cat escribió: Hola, para la GIV-6219 y la 6227 hay el catalogo de Gencat [1]. Además Gencat dispone de la base cartográfica de carreteras para su descarga [2]. Y antes que preguntéis el aviso legal dice que se debe contactar con el departamento en cuestión, cosa que hice como es mi obligación y aún espero respuesta, y supongo que la esperaré toda la vida Aunque si somos unos cuantos que les decimos que queremos importar quizá contesten Salut! Jaume. [1] http://bit.ly/gIYrFH [2] http://bit.ly/fCm4Y5 On 02/20/2011 04:34 PM, Juan Luis Rodriguez wrote: El 19 de febrero de 2011 20:43, Roberto Plà p...@aire.org mailto:p...@aire.org escribió: ¿Hay alguna fuente en la que se pueda consultar la topología (Principio fin y principales cruces) del sistema de carreteras del Estado o autonómicas. Aunque sea una descripcion escrita no grafica. Para solventar ducas sobre etiquetar una determinada via, como por ejemplo la GIV-6219 que va de Siurana a...¿Tonyà? ...¿A la GIV-6227? Aquí [1] tienes las de Andalucía. En concreto, en este PDF [2] está lo que preguntas. Un saludo, Juan Luis. [1] http://www.juntadeandalucia.es/obraspublicasyvivienda/portal-web/web/areas/transportes_infraestructuras/infraestructuras/texto/92023603-8a71-11df-9aa8-00163e67c14a [2] http://www.juntadeandalucia.es/obraspublicasyvivienda/estaticas/sites/consejeria/areas/transportes_infraestructuras/documentos/memoria_listado.pdf -- Juan Luis Rodríguez Ponce Área de Proyectos www.emergya.es http://www.emergya.es/ ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Jorge Juan -- Jorge Juan ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
[Talk-es] A vueltas con las intersecciones, las rutas y las restricciones de giro
Buenas Hace unos días envié un mensaje a la lista comentando el tema de las intersecciones y los cálculos de rutas que te permitían hacer giros en líneas continuas. La solución era añadir relaciones de restricciones de giro, pero la cosa aún sigue teniendo fallos y quería comentarlos. La intersección está aquí http://osm.org/go/b7J_GEBpj-- y comento con imágenes los tres enrutadores que he probado: CloudMade http://maps.cloudmade.com Lo hace bien y lo hace mal Bien: http://i.imgur.com/Q4RU0.png Mal: http://i.imgur.com/s6laB.png En el segundo ejemplo, donde se unen las vías de sentido único con la de doble sentido hay una restricción de giro no_u_turn pero creo que el enrutador se hace un lío e ignora la restricción porque esas mismas vías pertenecen a otra relación no_u_turn en la parte superior. Yournavigation http://www.yournavigation.org Lo hace mal http://i.imgur.com/jzR3v.png No sólo porque ignora una relación de seguir de frente (aunque creo que está mal definida, JOSM suelta errores), sino que salta de una vía a otra que están físicamente separadas por cebreado. OpenRouteService http://openrouteservice.org También lo hace mal http://i.imgur.com/pP1PG.png Al estilo de YourNavigation pero a la ruta le sale un pico que no entiendo. Qué opináis vosotros? ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Hola!
Buenas colisteros. SPAM, puro y duro. Nada que me han spoofiteao la cuenta de correo, me han suplantado la identidad, me han debido fichar la contraseña y ala a mandar SPAM, tanto que me han bloqueado la cuenta directamente los de google, como vereis ya la he recuperao, pero me han borrao todo lo que tenia en la nube de google. Bueno espero que no se repita, ahora ya entro por protocolo seguro, he cambiado la contraseña, estoy actualizando el sistema operativo y pasando un antivirus. Creo yo que me la han podido fichar a lo mejor por utilizar el movil para leer el correo, o que tenga una aplicacion cabrona que tiene acceso a esas contraseñas. El mu cabron que me ha fichao la cuenta es Argentino y los ataques han venido desde aqui, Móvil Argentina (190.245.160.68) 20 feb (hace 1 día) Navegador Argentina (186.61.10.184) Naa se me hacia raro a mi que pudieran acceder virus a las cuentas de google, y mi ordenador esta limpio, asi que seguro que me han fichado la contraseña por utilizar el ordenador de un amigo que tenia m´´as virus que kbytes en su disco duro. Siento mucho los incovenientes que os ha podido ocasionar. Un saludo. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] source=catastro y user=antecessor
On Domingo, 20 de Febrero de 2011 14:17:19 Marc Puig Pasarrius escribió: Ya tengo su respuesta, me ha dicho que dejará de importar edificios y eliminará los ya importados. Tema zanjado. OK. Si hay algún problema para borrar, coméntamelo, y paso nota al Data Working Group de la OSMF para que echen un vistazo. Y a ver si surge la oportunidad de hablar con Catastro de nuevo... Ciao, -- Iván Sánchez Ortega i...@sanchezortega.es i...@geonerd.org ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-ca] Coastline vs. water
I'm not seeing any problems. Bounding box or way id or screenshots would help. Copied from [1]: At low zoom levels, up to and including zoom level 9, Mapnik renders all the sea as a solid fill of blue, generated from the shapefile shoreline_300 (used for z0-9), which has a relatively low resolution. At high zoom levels the coast polygons used are generated from the natural=coastline tag -- the data is made available to the Mapnik renderer as a large shapefile (processed_p) which is generated every few weeks from planet dumps (note: if you edit coastline at high zooms, be patient for it to render). So you are only affecting the high zoom levels, if I understand correctly. You'll need to make sure the coastline ways create a closed loop of ways, of course. Adam [1]: http://wiki.openstreetmap.org/wiki/Coastline On Mon, Feb 21, 2011 at 11:30 AM, Samuel Dyck samueld...@gmail.com wrote: Hi I changed the tagging on the lower part of Lake Winnipeg from water to coastline so it would show up on lower zoom levels. But now the area I changed has disappeared from higher zoom levels. I know coastline tagged way only update ever few weeks, but I thought it only affected lower levels. I am incorrect? Sam Dyck ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Proposal: Cleanup of NHN ways in BC
On Mon, 2011-02-21 at 23:23 -0800, Paul Norman wrote: Existing tagging: Currently there are two types of tagging for waterways that were imported. The first of these is that for smaller waterways accuracy:meters=10 attribution=Natural Resources Canada oneway=yes source=GeobaseNHN_Import_2009 waterway=stream waterway:type=observed It seems to me that oneway is not appropriate. It indicates a legal restriction on traffic and AFAIK there is no Canada wide restriction that all traffic on all waterways must be in the direction of the flow, which this tagging would imply. -- Kevin Michael Smith smit...@draconic.ca signature.asc Description: This is a digitally signed message part ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
