Re: [Talk-hr] Fw: [Announce] Redaction progress
Evo alata koji pokazuje što je obrisano: http://tools.geofabrik.de/osmi/debug.html?view=botlon=15.93413lat=45.79364zoom=11opacity=1.00overlays=overview,bot_point_modified,bot_line_modified_cp,bot_line_modified,bot_point_deleted,bot_line_deleted_cp,bot_line_deleted Na posao! Janko ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Fw: [Announce] Redaction progress
Prebacio sam na Redaction bot ali ne vidim da je išta obrisano... On Mon, Jul 23, 2012 at 10:21 AM, Janko Mihelić jan...@gmail.com wrote: Evo alata koji pokazuje što je obrisano: http://tools.geofabrik.de/osmi/debug.html?view=botlon=15.93413lat=45.79364zoom=11opacity=1.00overlays=overview,bot_point_modified,bot_line_modified_cp,bot_line_modified,bot_point_deleted,bot_line_deleted_cp,bot_line_deleted Na posao! Janko ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr -- follow me - www.twitter.com/valentt http://kernelreloaded.blog385.com linux, anime, spirituality, wireless, scuba, linuxmce smart home, zwave ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turko...@hotmail.com ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
[OSM-talk-be] De Lijn
Hello, (it only concerns dutch people). Morgen gaat de Lijn weer een verandering doorvoeren, en op 1 september nog eens. Is er iemand die meer gegevens heeft, want bvb voor mij splitst de bus Ieper De panne op in Ieper Veurne en overstap. Wellicht is er per buslijn wel wat dat verandert, met de besparingen. Ik vraag me af hoe snel wij kunnen reageren met de gegevens? In ieder geval het recentste bestand dat ik kan afhalen is van 21/7/2012. Is er iemand die een kaart kan genereren bvb? Marc -- The Penguin has arrived - and he's not going away - ever. What's on Shortwave guide: choose an hour, go! http://shortwave dot tk 700+ Radio Stations on SW http://swstations dot tk 300+ languages on SW http://radiolanguages dot tk ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
[OSM-talk] Coastline generation resumed
I have resumed my daily generation of coastline files. These are generated with the coastcheck program[1] from my jxapi database starting at 5 AM pacific time. They take 3-4 hours to generate and upload, depending on my internet speed at the time. The completed files are uploaded to http://pnorman.dev.openstreetmap.org/coastlines/ If opening these shapefiles in QGIS be sure to create a spatial index for tolerable performance. There is a visualization of errors at http://www.wightpaths.co.uk/coast/ Many of the errors appear to be short errors between ways that became disconnected. More complicated errors are often best fixed by deleting the bad coastline and retracing. [1]: http://svn.openstreetmap.org/applications/utils/coastcheck/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] ODbL Attribution
In preparation for the release of an ODbL-Licensed planet I have been looking around what the official proper attribution will be, so that I can update all sites where I am using OSM data. I didn't find anything on the Wiki. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] What's new in cartography
Find out what's is new in cartography at the ICA Neocartography workshop, UCL Sept 5th Details and registration (it's free) at: http://neocartography.icaci.org/ There may well be sessions of interest to you at the Society of Cartographers Conference. Presenters include David Earl, Andy Allan, Harry Wood, Ollie O'Brien and Steve Chilton. Details and booking at: http://www.soc2012.soc.org.uk/ Cheers Steve Steve Chilton FSEDA, Learning Support Fellow Educational Development Manager Centre for Learning and Teaching Enhancement Middlesex University phone: 020 8411 5355 email: ste...@mdx.ac.uk Profile: http://www.middlesex.wikispaces.net/user/view/steve8 Chair of the Society of Cartographers: http://www.soc.org.uk/ Chair of ICA Neocartography Commission: http://www.soc.org.uk/neocartography/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Very Happy - Looking forward
Rob Nickerson wrote What's your wish-list? I'd love to see a fully-featured editor that can be used in the field, running on GPS-enabled smartphones and tablets. How great would it be to add details of a way or feature while you are stood right next to it? I imagine entering the way's name and type, then simply walking along it to add it, perhaps adding other nodes and features as you go. Hopefully Richard Fairhurst's iD project, creating a new editor in Javascript, is the beginning of such a tool: http://www.geowiki.com/ -- View this message in context: http://gis.19327.n5.nabble.com/Very-Happy-Looking-forward-tp5717753p5717945.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] ODbL Attribution
Jochen123 wrote: In preparation for the release of an ODbL-Licensed planet I have been looking around what the official proper attribution will be, so that I can update all sites where I am using OSM data. I didn't find anything on the Wiki. A couple of months back I wrote http://wiki.openstreetmap.org/wiki/Legal_FAQ/ODbL and threw it out for review by people. cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/ODbL-Attribution-tp5717937p5717949.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] Coastline generation resumed
On Mon, Jul 23, 2012 at 8:55 AM, Paul Norman penor...@mac.com wrote: There is a visualization of errors at http://www.wightpaths.co.uk/coast/ Many of the errors appear to be short errors between ways that became disconnected. More complicated errors are often best fixed by deleting the bad coastline and retracing. Thanks a lot! -- -S ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Changes in OSM Inspector: WTFE layer gone, new Redaction layer
Hi, OSM Inspector has a new layer that visualizes the work of the redaction bot: http://tools.geofabrik.de/osmi/?view=redactionbotlon=7.84268lat=48.78466zoom=5 It looks similar to the old WTFE layer which is now discontinued, but the layers are slightly different: RED is for stuff deleted by the bot. You will be able to click on individual items and see the tags of the deleted object with a big WARNING saying that you must not copy that to OSM. Please heed the warning. ORANGE is for stuff where the bot is the last editor of something; these things might require checking. There is no access to pre-redaction versions of such objects via OSMI. YELLOW is for stuff that has been edited by the bot, but someone else has edited it again since, so it is likely that the yellow stuff has been checked/repaired already. There is currently no way to clear the red stuff from the OSMI display but I'm hoping to build something later. The new data should be available as tiles as well, if you just replace wtfe with redactionbot in the URL. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] FYI - Automated edit: footway - sidewalk
FYI, please provide any feedback to the original author on the forum. http://forum.openstreetmap.org/viewtopic.php?id=17526 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changes in OSM Inspector: WTFE layer gone, new Redaction layer
Hi Frederik, thank you very much ... that helps a lot. Is it possible to offer this map type (with all overlays) in Map Compare as well? M. --- sorry for TOFU ;-) 2012/7/23 Frederik Ramm frede...@remote.org Hi, OSM Inspector has a new layer that visualizes the work of the redaction bot: http://tools.geofabrik.de/**osmi/?view=redactionbotlon=7.** 84268lat=48.78466zoom=5http://tools.geofabrik.de/osmi/?view=redactionbotlon=7.84268lat=48.78466zoom=5 It looks similar to the old WTFE layer which is now discontinued, but the layers are slightly different: RED is for stuff deleted by the bot. You will be able to click on individual items and see the tags of the deleted object with a big WARNING saying that you must not copy that to OSM. Please heed the warning. ORANGE is for stuff where the bot is the last editor of something; these things might require checking. There is no access to pre-redaction versions of such objects via OSMI. YELLOW is for stuff that has been edited by the bot, but someone else has edited it again since, so it is likely that the yellow stuff has been checked/repaired already. There is currently no way to clear the red stuff from the OSMI display but I'm hoping to build something later. The new data should be available as tiles as well, if you just replace wtfe with redactionbot in the URL. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 __**_ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talkhttp://lists.openstreetmap.org/listinfo/talk -- ## Manfred Reiter - - ## A. Because it breaks the logical sequence of discussion ## Q. Why is top posting bad? ## unsere IT-Zertifikate: http://www.bbs-hermeskeil.de/images/ingot-award(3).pdf ## Kriterien für den Erwerb: http://de.theingots.org/community/node/10592 ## Please avoid sending me Word or PowerPoint attachments. ## See: http://www.gnu.org/philosophy/no-word-attachments.html ## INGOTs Assessor Trainer ## (International Grades in Open Technologies) ## www.theingots.org ## www.igab-saar.de - Brückendemo 2007 - 4500 Menschen ## 16.02.2008 - Aktionstag Saarlouis - 7.000 Menschen ## 23.02.2008 - an der Katastrophe vorbeigeschrammt - 60.000 Menschen ## 24.02.2008 - Demo Saarwellingen - 6.000 Menschen - Der Schlossplatz ist zu klein ## 16.09.2008 - Entzug Rahmenbetriebsplan-Zulassung für die Primsmulde Süd und Nord ## 01.10.2008 - Abbaubeginn in Reisbach (Wahlschied West 8.5) im Sofortvollzug ## 15.12.2009 - Abbaubeginn in Reisbach (Wahlschied Ost 8.5) im Sofortvollzug ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changes in OSM Inspector: WTFE layer gone, new Redaction layer
2012/7/23 Manfred A. Reiter ma.rei...@gmail.com Hi Frederik, thank you very much ... that helps a lot. Is it possible to offer this map type (with all overlays) in Map Compare as well? M. --- sorry for TOFU ;-) and now SORRY for the sig :-( ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Very Happy - Looking forward
I've often thought of the idea of a Footpath editor which could be used in the field to automatically add footpaths/bridleways to OSM. It should be possible to do, though it would rely on connecting to the live API in the field to both read and write data, to avoid duplication. As it would be used in the countryside, it would be hoped that the amount of surrounding OSM data would be small so it wouldn't overload the servers or require silly amounts of data to be downloaded. It would have to work something like this: Work out the bounding box with the surveyor at the centre, say a bounding box of 100 metres Get the ways and draw them Ask user whether they want to survey If so, start recording GPS track User stops when required and enters the path type (high level or detailed tags) Algorithm to automatically simplify GPS track User selects connection points to existing network (these become first and last nodes of the new way) Way is uploaded What would be nice, and make these sorts of clients easier to develop, would be API calls to throw a load of lat/lons at the server and have the server automatically plug it into the existing network by working out what existing nodes the new way will use, though obviously this would require extra server power. Nick -Graham Stewart (GrahamS) gra...@dalmuti.net wrote: - To: talk@openstreetmap.org From: Graham Stewart (GrahamS) gra...@dalmuti.net Date: 23/07/2012 09:40AM Subject: Re: [OSM-talk] Very Happy - Looking forward Rob Nickerson wrote What's your wish-list? I'd love to see a fully-featured editor that can be used in the field, running on GPS-enabled smartphones and tablets. How great would it be to add details of a way or feature while you are stood right next to it? I imagine entering the way's name and type, then simply walking along it to add it, perhaps adding other nodes and features as you go. Hopefully Richard Fairhurst's iD project, creating a new editor in Javascript, is the beginning of such a tool: http://www.geowiki.com/ -- View this message in context: http://gis.19327.n5.nabble.com/Very-Happy-Looking-forward-tp5717753p5717945.html Sent from the General Discussion mailing list archive at Nabble.com. ___ 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] Very Happy - Looking forward
*Sören Gasch said:* * * Improve ease of editing (like wheelmap, a simple editor that lets** you amend JUST the tags - name, opening hoursm, url etc..).*There will be the Amenity Editor which kind of does what you propose. See - http://ae.osmsurround.org/ - http://wiki.openstreetmap.org/wiki/Amenity_Editor *and Roland Olbricht said:* * * Make it easy to users to view the data (eg clicking a node/way could** bring up data about it - the url and opening hours tags are not visible in** map renders but is very useful to many end users)* There is already a prototype that does show all datahttp://overpass-api.de/open_layers_popup.html http://overpass-api.de/open_layers_popup.html Wow these both look really good. The editor would really decrease the barrier to entry (e.g. shop owners could easily add their opening hours). What's holding this project back from being more prominently placed on the map front page / How can I help? Regards, RobJN ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Very Happy - Looking forward
On 23 July 2012 16:54, Rob Nickerson rob.j.nicker...@gmail.com wrote: Sören Gasch said: * Improve ease of editing (like wheelmap, a simple editor that lets you amend JUST the tags - name, opening hoursm, url etc..). There will be the Amenity Editor which kind of does what you propose. See - http://ae.osmsurround.org/ - http://wiki.openstreetmap.org/wiki/Amenity_Editor and Roland Olbricht said: * Make it easy to users to view the data (eg clicking a node/way could bring up data about it - the url and opening hours tags are not visible in map renders but is very useful to many end users) There is already a prototype that does show all data http://overpass-api.de/open_layers_popup.html Wow these both look really good. The editor would really decrease the barrier to entry (e.g. shop owners could easily add their opening hours). What's holding this project back from being more prominently placed on the map front page / How can I help? Also, there's also the newer iD (http://www.geowiki.com/, http://www.geowiki.com/iD/) which is aiming to be a simple tag and POI editor. It's not fully working yet but I imagine that development will happen fast. -- Matt Williams http://milliams.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changes in OSM Inspector: WTFE layer gone, new Redaction layer
OSM Inspector has a new layer that visualizes the work of the redaction bot: http://tools.geofabrik.de/osmi/?view=redactionbotlon=7.84268lat=48.78466zoom=5 Does not yet work at mine. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Greetings
Hello everyone. This is to advice you all that my absence from talk does not mean I am not available for talk. Pardon my absence from talk and let us resume conversation. Thank you. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] City routing grid for Australia and the US
I've not checked the tool in details but if I understand correctly, the reference distance numbers are coming from Google API. Imo, massively extracting distance like this is a copyright infringement, even if it's just to compare, in the same way using GMaps to check the street names correctness in OSM. Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OT - Unusual Bing imagery
Mike N wrote on 19/07/2012 at 12:43:19 +1100 subject [OSM-talk] OT - Unusual Bing imagery : I spotted this today as I was entering survey information: http://greenvilleopenmap.info/Airplane.jpg I didn't realize that the Bing planes flew so high. If you give the location of this image, it would be possible to look for its shadow and calculate an approximate altitude. The Bing imagerie could be satellite imagerie, not necessarily air plane imagerie. -- Sincerely Hendrik Oesterlin - New Caledonia ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OT - Unusual Bing imagery
On 24 July 2012 00:52, Hendrik Oesterlin hendrikmail2...@yahoo.de wrote: http://greenvilleopenmap.info/Airplane.jpg If you give the location of this image, it would be possible to look for its shadow and calculate an approximate altitude. The Bing imagerie could be satellite imagerie, not necessarily air plane imagerie. The area in the screenshot seems to have a higher resolution than satellites can achieve. Also I've stumbled on big airliners in Yahoo or Bing satellite imagery before and they look much different (longer exposition time and the RGB components somehow have an offset because of the altitude difference, like here: http://www.streetviewfun.com/2010/airplane-on-satellite-image-2/) Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Polygon or WPS
hi all anyone working with POI pattern, i am working on it, still dunno how to draw polygon between POI, in my case, 1 POI = 1 identified species, so if we have 100 POI, mean we have distribution of species in one area i want to draw a polygron on top of it, and create simulation, yes, look like moving prediction the model may be can be used also for simulate disease. i got Zoo Project, but still wanna to know deeply how to integrate with mapnik. -- Frans Thamura (曽志胜) Shadow Master and Lead Investor Meruvian. Integrated Hypermedia Java Solution Provider. Mobile: +628557888699 Blog: http://blogs.mervpolis.com/roller/flatburger (id) FB: http://www.facebook.com/meruvian TW: http://www.twitter.com/meruvian / @meruvian Website: http://www.meruvian.org We grow because we share the same belief. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OT - Unusual Bing imagery
At 2012-07-23 16:02, andrzej zaborowski wrote: On 24 July 2012 00:52, Hendrik Oesterlin hendrikmail2...@yahoo.de wrote: http://greenvilleopenmap.info/Airplane.jpg Nice catch, Mike N. Finding a plane in flagrante used to be quite an achievement in the KHBBS days :) The Bing imagerie could be satellite imagerie, not necessarily air plane imagerie. The area in the screenshot seems to have a higher resolution than satellites can achieve. Is this documented somewhere? Assuming from the look and ratio of measurements of the jet that it is a B737, the pic is at z20 (~12cm/pel @ middle lats). I was under the impression that all of the Bing/Yahoo/Google imagery was still satellite-based, down to z21 (6cm/pel). I know Google has spots of UHR imagery at z22, but it seems they were still referred to as satellite. I've seen individual county websites with very nice imagery described as flyover, as though coming from airplane/helicopter, apparently on a contract basis. -- Alan Mintz alan_mintz+...@earthlink.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OT - Unusual Bing imagery
On 24 July 2012 03:48, Alan Mintz alan_mintz+...@earthlink.net wrote: At 2012-07-23 16:02, andrzej zaborowski wrote: The area in the screenshot seems to have a higher resolution than satellites can achieve. Is this documented somewhere? Assuming from the look and ratio of measurements of the jet that it is a B737, the pic is at z20 (~12cm/pel @ middle lats). I was under the impression that all of the Bing/Yahoo/Google imagery was still satellite-based, down to z21 (6cm/pel). I know Google has spots of UHR imagery at z22, but it seems they were still referred to as satellite. I've seen individual county websites with very nice imagery described as flyover, as though coming from airplane/helicopter, apparently on a contract basis. I've assumed 0.5m/px is the technical limit for satellite imaging, Wikipedia seems to confirm this more or less: The latest commercial satellite (GeoEye 1) has a GSD of 0.41 m (effectively 0.5 m due to United States Government restrictions on civilian imaging).[1] I guess military satellites might have better parameters, but anything you're likely to see on the web with a higher resolution will be taken from within the troposphere. I've been told once that 0.5m is the usual limit around the world except Israel of which you're unlikely to see imagery better than 2m due to the government's threats. Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OT - Unusual Bing imagery
From: andrzej zaborowski [mailto:balr...@gmail.com] Subject: Re: [OSM-talk] OT - Unusual Bing imagery On 24 July 2012 03:48, Alan Mintz alan_mintz+...@earthlink.net wrote: At 2012-07-23 16:02, andrzej zaborowski wrote: The area in the screenshot seems to have a higher resolution than satellites can achieve. Is this documented somewhere? Assuming from the look and ratio of measurements of the jet that it is a B737, the pic is at z20 (~12cm/pel @ middle lats). I was under the impression that all of the Bing/Yahoo/Google imagery was still satellite-based, down to z21 (6cm/pel). I know Google has spots of UHR imagery at z22, but it seems they were still referred to as satellite. I've seen individual county websites with very nice imagery described as flyover, as though coming from airplane/helicopter, apparently on a contract basis. I've assumed 0.5m/px is the technical limit for satellite imaging, Wikipedia seems to confirm this more or less: The latest commercial satellite (GeoEye 1) has a GSD of 0.41 m (effectively 0.5 m due to United States Government restrictions on civilian imaging).[1] I guess military satellites might have better parameters, but anything you're likely to see on the web with a higher resolution will be taken from within the troposphere. I've been told once that 0.5m is the usual limit around the world except Israel of which you're unlikely to see imagery better than 2m due to the government's threats. This matches up with what I've heard in discussions with one of the cities about their imagery. Another factor is not the resolution but the image quality. Satellite photos have to go through more air which can cause the loss of some information and lower-contrast imagery. On the other hand, a lot of aerial imagery out there is film-based which does not generally have colour and contrast as good as digital aerial imagery. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Very Happy - Looking forward
Great spirit! Now that we're past this milestone, it opens up our headspace and energy for building what's next Wish there was a place to consistently capture these ideas, and put movement behind them. There's a bunch of stuff on the wiki http://wiki.openstreetmap.org/wiki/Category:Usability http://wiki.openstreetmap.org/wiki/Things_To_Do Several lists, groups, processes. http://wiki.openstreetmap.org/wiki/Design_Mailing_List http://www.osmfoundation.org/wiki/Engineering_Working_Group My interest is still in building out social features http://brainoff.com/weblog/2012/03/30/1773 * Mikel Maron * +14152835207 @mikel s:mikelmaron From: Matt Williams li...@milliams.com To: talk@openstreetmap.org Sent: Monday, July 23, 2012 9:14 AM Subject: Re: [OSM-talk] Very Happy - Looking forward On 23 July 2012 16:54, Rob Nickerson rob.j.nicker...@gmail.com wrote: Sören Gasch said: * Improve ease of editing (like wheelmap, a simple editor that lets you amend JUST the tags - name, opening hoursm, url etc..). There will be the Amenity Editor which kind of does what you propose. See - http://ae.osmsurround.org/ - http://wiki.openstreetmap.org/wiki/Amenity_Editor and Roland Olbricht said: * Make it easy to users to view the data (eg clicking a node/way could bring up data about it - the url and opening hours tags are not visible in map renders but is very useful to many end users) There is already a prototype that does show all data http://overpass-api.de/open_layers_popup.html Wow these both look really good. The editor would really decrease the barrier to entry (e.g. shop owners could easily add their opening hours). What's holding this project back from being more prominently placed on the map front page / How can I help? Also, there's also the newer iD (http://www.geowiki.com/, http://www.geowiki.com/iD/) which is aiming to be a simple tag and POI editor. It's not fully working yet but I imagine that development will happen fast. -- Matt Williams http://milliams.com ___ 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: [talk-au] Redaction progress
On Sat, Jul 21, 2012 at 10:33 PM, David Sisourath someperson_...@hotmail.com wrote: hard as few people edit and go around in the Western Region of Melbourne. I've actually done a fair bit in the northwest, over the last few years - especially the new suburbs like Delahey, Roxburgh Park, etc. I'm not picky where I edit in Victoria - happy to work on any white spaces anywhere, as long as there's imagery. Steve ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Getting back into it
Working on Sydney-Newcastle at the moment... things are missing all over the place. I'm less confident remapping railways outside the areas in which I have personal experience (eg Melbourne-Sydney) especially where there is a lack of clear aerial imagery... but I'll keep plugging away. BJ Sent from my iPad On 23/07/2012, at 20:00, Steve Bennett stevag...@gmail.com wrote: Hi Ben, Great to hear it. I think a fair bit of the Melbourne-Sydney rail line has been lost - last I checked, anyway. Steve On Mon, Jul 23, 2012 at 5:03 AM, Ben Johnson tangarar...@gmail.com wrote: Hi all, Just re-introducing myself... This is Ben from the Central Coast (NSW). I've been off the grid for a while... some of you might remember I'm a Sydney-based train driver, and I re-mapped most of Sydney's rail network before the redaction... it took weeks of solid work and I burnt myself out in the process and lost interest in the whole thing. But i have been quietly lurking and watching in horror as the redaction progressed. I now feel i need to get back into it. If nobody else is doing it, I'm going to try fixing up Hawkesbury River this week... I like Paul Haydon's suggestion of a hierarchy of priorities and maybe staring by focusing attention on major waterways and arterial roads... so that's the approach I'm going to take... but I'm going to mix the approach with maintaining a focus on the local areas and features I know best. BJ Sent from my iPad ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[talk-au] How to find missing bits?
Hi all, Now that the CLEANMAP/BADMAP server has been disabled, what's a good way to find missing bits? Are there any sites that compare pre- and post- redaction? Steve ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] How to find missing bits?
On Mon, Jul 23, 2012 at 8:31 PM, Steve Bennett stevag...@gmail.com wrote: Hi all, Now that the CLEANMAP/BADMAP server has been disabled, what's a good way to find missing bits? Are there any sites that compare pre- and post- redaction? As announced on dev@ http://lists.openstreetmap.org/pipermail/dev/2012-July/025318.html OSMI. Sorry for the long link. http://tools.geofabrik.de/osmi/?view=redactionbotlon=132.84375lat=-21.45920zoom=3overlays=overview,bot_point_superseded,bot_line_superseded_cp,bot_line_superseded,bot_point_modified,bot_line_modified_cp,bot_line_modified,bot_point_deleted,bot_line_deleted_cp,bot_line_deleted ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [Talk-is] Árangur í Hafnarfirði
Nú er þetta komið lengra en ég er búinn að setja inn íbúðarhverfin fyrir utan fáeinar götur hér og þar. Þá er að koma að þeirri stundu að ég fari milli fyrirtækja í upplýsingasöfnun. Mig langar að fá álit ykkar á eyðublaði sem ég ritaði af því tilefni (og er í viðhengi). Ég myndi s.s. fara með eintök af því milli fyrirtækja (verslana) og fylla út. Einnig leita ég að sjálfboðaliðum til þess að aðstoða mig með þetta. - Svavar Kjarrval On 18/07/12 21:39, Ævar Arnfjörð Bjarmason wrote: Þetta er frábært, vel gert! 2012/7/18 Svavar Kjarrval sva...@kjarrval.is: Hæ. Eftir mikla vinnu get ég með ánægju sagt að Hafnarfjörður er ágætlega nálægt því að vera kláraður. Flestar, ef ekki allar götur, hafa verið leiðréttar í samræmi við BING loftmyndirnar og húslínur eru til staðar svo langt sem loftmyndirnar leyfa. Meiri hluti húsa bæjarins hafa verið merkt með húsnúmerum og tengdar við götur en það ferli mun líklegast klárast á næstu tveim vikum. Mig langar að biðja ykkur um að nostra smá við bæinn líka svo hægt sé að senda út fréttatilkynningu þegar það helsta er komið. Það sem mætti gera er að bæta við fleiri gangstígum, gangbrautum, notkun landsvæða (landuse tagið) og fleira sem hægt er að álykta út frá loftmyndunum. Ef ykkur grunar að eitthvað sé rangt en skortir upplýsingar til að laga það, merkið villuna með OpenStreetBugs. Húsnúmeramerking og POI söfnun er í gangi af minni hálfu en það myndi varla saka ef þið gætuð bætt við því sem þið vitið af nú þegar. Með kveðju, Svavar Kjarrval ___ Talk-is mailing list Talk-is@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-is ___ Talk-is mailing list Talk-is@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-is OSM eyðublað.odt Description: application/vnd.oasis.opendocument.text signature.asc Description: OpenPGP digital signature ___ Talk-is mailing list Talk-is@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-is
Re: [Talk-is] Árangur í Hafnarfirði
Svakalegur dugnaður er þetta í þér Svavar! Mér líst vel á þetta eyðublað. Einfalt og gott. Gæti verið sniðugt að hafa eitthvað með þér um OSM til að sýna í fyrirtækjunum, annað hvort á pappírsformi eða í einhverju appi í símanum. Kv. Þórir Már - Svavar Kjarrval On 18/07/12 21:39, Ævar Arnfjörð Bjarmason wrote: Þetta er frábært, vel gert! 2012/7/18 Svavar Kjarrval sva...@kjarrval.is: Hæ. Eftir mikla vinnu get ég með ánægju sagt að Hafnarfjörður er ágætlega nálægt því að vera kláraður. Flestar, ef ekki allar götur, hafa verið leiðréttar í samræmi við BING loftmyndirnar og húslínur eru til staðar svo langt sem loftmyndirnar leyfa. Meiri hluti húsa bæjarins hafa verið merkt með húsnúmerum og tengdar við götur en það ferli mun líklegast klárast á næstu tveim vikum. Mig langar að biðja ykkur um að nostra smá við bæinn líka svo hægt sé að senda út fréttatilkynningu þegar það helsta er komið. Það sem mætti gera er að bæta við fleiri gangstígum, gangbrautum, notkun landsvæða (landuse tagið) og fleira sem hægt er að álykta út frá loftmyndunum. Ef ykkur grunar að eitthvað sé rangt en skortir upplýsingar til að laga það, merkið villuna með OpenStreetBugs. Húsnúmeramerking og POI söfnun er í gangi af minni hálfu en það myndi varla saka ef þið gætuð bætt við því sem þið vitið af nú þegar. Með kveðju, Svavar Kjarrval ___ Talk-is mailing list Talk-is@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-is ___ Talk-is mailing list Talk-is@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-is ___ Talk-is mailing list Talk-is@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-is ___ Talk-is mailing list Talk-is@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-is
Re: [Talk-de] GPX-Dateien wiederfinden (was: Zurueck in die Steinzeit)
Bodo Meissner wrote: falls Du in Deinen GPX-Dateien die richtigen herausfinden möchtest, probiere mal in JOSM das Plugin openvisible. (Kann aber bei einer großen Menge an Dateien lange dauern, bis JOSM alle untersucht und die richtigen gefunden hat.) Danke für den Tipp. | joerg@cm:~/Desktop/OSM/GPX$ du -h | 291M ./2008 | 362M ./2009 | 289M ./2010 | 55M ./2007 | 279M ./2011 | 1011M . | joerg@cm:~/Desktop/OSM/GPX$ Ich schau demnächst mal ob er das noch frisst. Insgesamt sind das so 15.000km mit dem Rad... Wie schon geschrieben, die Dateien haben zwar eindeutige Zeitstempel aber sonst keine weiteren Angaben die mir beim verorten helfen würden. War halt nur das Backup. LG Jörg -- There are only 10 types of people in the world: Those who understand binary, and those who don't... signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Am 22.07.2012 22:57, schrieb Stefan Keller: Meine/unsere externe DB sollte sich da vorher schon klar gemacht haben, bevor sie die Projekt-IDs in OSM einträgt, ob sie Supermärkte (oder was auch immer) nun als Punkte oder Flächen (oder beides) modelliert. Je nachdem wird dann darauf reagiert. Dann verstehe ich nicht, warum sie eine Referenz braucht. Wenn die externe Datenbank entscheidet, wie OSM das zu modellieren hat bzw. zu welchem Modell/welchen Daten sie verlinkt, dann kann sie auch direkt eine Kopie des Objekts halten. Bei Änderungen in OSM ist sie aufgeschmissen, aber das ist sie ja bei deiner Lösung sowieso im Zweifelsfall. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wochennotiz Nr. 105
Hallo, die Wochennotiz Nr. 105 mit allen wichtigen Neuigkeiten aus der OpenStreetMap Welt ist da: https://blog.openstreetmap.de/2012/07/wochennotiz-nr-105/ Viel Spaß beim Lesen! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Am 22.07.2012 23:34, schrieb Stefan Keller: Hallo Henning (aighes) Am 22. Juli 2012 23:05 schrieb aighes o...@aighes.de: Am 22.07.2012 22:45, schrieb Stefan Keller: Am 22. Juli 2012 22:14 schrieb aighes o...@aighes.de: Oder wenn jemand das Objekt nun anderweitig nutzt. Bspw. Straße - Gebäude. Dann hat auf einmal das Gebäude die ref der Straße. Verstehe ich nicht. Jedenfalls bin ich mit dir gleicher Meinung, dass OSM nicht eine Datenbank für alle sein kann und einfach vollgestopft werden soll mit Tags, die von externen Projekten kommen. Der einzige Tag den ich vorschlage ist diese eine Projekt_ID. Nein. Die ID hilft keinem bei der sicheren Zuordnung. Es hat keinen Vorteil gegenüber der normalen Objekt-ID. Doch: Es ist permanent/stabil/eindeutig (falls einem die OSM ID nicht genügt). Bsp: Restaurant als Node eingetragen mit Projekt-ID. Nun wird aus dem Restaurant eine Fläche und der Node wird bspw. eine Parkbank und behält die Projekt-ID. Der normale Mapper wird sich darum nicht kümmern, weil es ihm nichts sagt und er auch nicht weiß, ob die ID nun zum Node an sich gehört, oder zu dem Objekt Restaurant. Das mit dem Verschieben von Node zu Fläche habe ich oben beantwortet. Wenn ein Mapper aus einen Restaurant als Node eine Parkbank macht, dann stimmte entweder tatsächlich vorher etwas nicht mit der Realität überein (und die externe Datenank registriert das) oder mit dem Mapper Mit dem Mapper stimmt alles, denn OSM-IDs sind Schall und Rauch und nur zur akuten Verwendung zwischen Objekten stabil - und an der Stelle hat der Mapper definitiv nichts falsch gemacht. Der betreffende Mapper ist eben vielleicht kein Datenbank-Fetischist, weiß unter Umständen nichtmal, was eine ID ist, und braucht das auch nicht wissen. :- Will anständigerweise sagen, er war sich seiner unbedarften Handlung nicht bewusst, und das Projekt ist so nett (zu OSM), erzeugt das Restaurant wieder (mit seiner Projekt-ID) und löscht die Projekt-ID beim Parkbank. Das Projekt - egal ob du damit jetzt den OSM-Server oder einen beliebigen Editor meinst, weiß aber nunmal gar nicht, ob der mapper damit wirklich das Objekt verändert hat. Vielleicht ist die Bushaltestelle gar nicht durch ein anderes Objekt ersetzt worden, sondern nur durch ein neues Taggingschema, das die Software noch nicht kennt - deshalb aber ja nicht verboten ist. Deine Lösung erfordert also entweder festgelegte Tagging-Regeln, damit solche Ersetzungsregeln auch nur ansatzweise funktionieren (denn auch ein nachträgliches hinzufügen/hinterherziehen neuer Taggingvarianten würde sonst ja das brechen von IDs nicht verhindern), oder aber es funktioniert schlichtweg nicht. Dass sich ein Objekt in zwei jeweils nur einzelne Aspekte dessen beschreibende teilt, ist damit übrigens auch noch nicht gelöst. Sinnvoller wäre es, bspw. über die OverpassAPI nach einem Restaurant mit dem Namen xyz in der BBox... zu fragen. Ok: Restaurants haben Namen (wenn auch kaum eindeutige), Parkbänke leider kaum. Daher ist die Idee der kombinierten Tags unzureichend. Ich mappe am Montag vier Bänke auf dem Marktplatz. Eine davon (!) bekommt am Dienstag eine ID nach deinem Schema vom schlafbank-projekt ;). Ich komme Freitags wieder vorbei und da stehen immer noch vier Parkbänke, aber nicht an der gleichen Stelle. Es ist definitiv nicht zu erkennen, ob die Bänke jetzt verschoben worden sind, oder ob das andere Bänke sind. Was soll ich als Mapper jetzt mit der ID machen? Was soll ich mit den Bänken machen? verschieben oder löschen und neu zeichnen? Noch etwas deutlicher eine Bundesstraße verlief durch den Ort und hat eine Projekt-ID bekommen. Nun wird eine Umgehung gebaut und das was vorher Bundesstraße war, ist nur noch Ortsstraße. Der Mapper weiß wieder nicht, ob die ID nun zur Bundestraße gehört oder zu der Straße an diesem Ort (können ja auch mehrere ID's an dem Way sein, die jeweils unterschiedliche Bezüge haben). Der Mapper hat hier die freie Wahl! Er soll einfach den Tag irgendwohin tun - nur in (wie üblich) nicht löschen. Das Projekt kümmert sich (hoffentlich) drum. Womit sich der Kreis schließt und das Projekt von den stabilen IDs überhaupt nichts gewonnen hat - denn jede Änderung an Objekten mit diesen IDs muss das Projekt manuell nachvollziehen und bei Bedarf korrigieren. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Off. Re: Zurueck in die Steinzeit
Am 21. Juli 2012 12:19 schrieb buedner bued...@gmx-topmail.de: Ich möchte aber zu bedenken geben, dass für jemanden, der nur OSM-Daten bearbeiten möchte, Potlatch ein hervorragendes Werkzeug ist. JOSM auch Der allergrößte Teil der Editierarbeiten ist damit ohne große Einarbeitungszeit effizient zu erledigen, übrigens auch für den Profi. dito in JOSM. Übrigens nicht nur ohne Einarbeitungszeit sondern vor allem auch mit weniger Wartezeit fürs Laden ;-) Ich empfinde daher die leichte Überheblichkeit, die hier gelegentlich gegenüber Potlatch-Nutzern zum Ausdruck kommt, als etwas peinlich. Es kann ja jeder den Editor benutzen, den er lieber hat, aber oft habe ich den Eindruck, Potlatch-Nutzer benutzen den deshalb, weil irgendwo jemand ins Wiki geschrieben hat, JOSM sei für Experten und Potlatch für Anfänger und Gelegenheitsmapper. M.E. ist das so Quatsch, und auch Anfänger und Gelegenheitsmapper könnten von JOSM profitieren, so sie ihn denn mal ausprobieren würden (vermute, dass bereits vorher von dem Experten-Mythos abgeschreckt werden, so dass sie JOSM gar nicht ausprobieren). Ich finde, das Wiki könnte durchaus etwas direkter sein, und z.B. anstatt nur zu schreiben, Potlatch erfordere keine Installation zusätzlich darauf hinweisen, dass dafür jedes Mal wenn man den Bildschirmausschnitt verschiebt mit Wartezeiten fürs Laden zu rechnen ist. Oder wenn man darauf hinweisen würde, dass PL z.B. keine Multipolygone mit mehreren outer ways unterstützt, und man diese daher extrem leicht versehentlich damit kaputt macht (no tags set, unknown). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Defekter Link auf deutsche Sprachversion der Lizenz
Hallo, auf http://www.openstreetmap.org/copyright/en funktioniert der Link nicht zurück auf den deutschen Text. Kann das bitte jemand aufräumen, der das kann? Danke! Gruß Lulu-Ann ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Neuer OSMI-Layer fuer Lizenzwechsel-Resultate
Hi, auf http://tools.geofabrik.de/osmi/?view=redactionbotlon=7.84268lat=48.78466zoom=5 gibt es einen neuen OSMI-Layer, der zeigt, was beim Lizenzwechsel-Bot passiert ist: ROT - Sachen, die der Bot geloescht hat. Der OSMI zeigt noch die alten Tags an, aber bitte nur angucken, nicht nach OSM hinein uebernehmen! ORANGE - Sachen, die der Bot geaendert hat. GELB - Sachen, die der Bot geanedert hat und die seitdem von jemand anders nochmal angefasst wurden. 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] Neuer OSMI-Layer fuer Lizenzwechsel-Resultate
On 23.07.2012 12:23, Frederik Ramm wrote: GELB - Sachen, die der Bot geanedert hat und die seitdem von jemand anders nochmal angefasst wurden. von der logischen Abstufung rot-orange-gelb her ist das zwar völlig OK und nachvollziehbar, aber mit der Sichtbarkeit von gelb hab ich so meine Probleme, insb. wenn es über highway=tertiary liegt ... :( -- hartmut ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Vorschlag Supersedes (was: Permanente/stabile OSM IDs!)
Stefan Keller wrote: Mich beschäftigt seit einiger Zeit die Frage von permanenten/stabilen OSM IDs und der Verknüpfung von OSM mit anderen Datenbanken. Ein neuer Vorschlag: Wie wäre es damit, es so wie im Usenet zu machen? Wenn ein Objekt durch ein anderes ersetzt wird, auf das neue einen supersedes-Tag setzen, der als Wert die alte Objekt-ID hält. Liebe Grüße, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Frederik Ramm wrote: ich bin der Ansicht, das OSM-IDs eine 100% OSM-interne Sache sind, auf die sich niemand sonst verlassen darf, weil dies die Handlungsmoeglichkeiten bei OSM einschraenkt. Mag ja sein, aber es gibt aktuell keine echte Alternative, ein Objekt in der OSM korrekt zu referenzieren. Es ist nunmal so, dass OSM-Intern die ID als Datenbank-Schlüssel verwendet wird und solange Mapper ein Objekt nicht komplett löschen und neu erzeugen (oder einen Node durch einen Way ersetzen, wie z.B. bei Gebäuden) ist die ID auch stabil. UUIDs stehe ich ebenfalls sehr kritisch gegenueber, weil sie das Fuehren der Link-Stabilitaet unseren Mappern aufbuerden. Und? Warum sollte nicht derjenige, der Daten aus der OSM nutzt, sich um die Dauerhaftigkeit dieser ID kümmern? Beispiel: Ich habe für unseren Heimat- und Geschichtsverein eine Karte gebaut, auf der alle Bildstöcke, Wegkreuze, Kirchen und Sehenswürdigkeiten als kleine Pinnadeln gezeigt werden. Beim Anklicken der Pinnadel geht ein Popup mit kurzem Text und einem Foto auf. Die Verknüpfung zwischen Punkt (Hole ich aus der OSM-DB) und Text + Foto mache ich aktuell anhand der ID. Wenn sich die ID mal ändert, dann muss ich in meiner DB eine Änderung durchführen. Hätte ich nun UUIDs, dann könnte ich stattdessen eine von einem Mapper kaputtgemachte UUID einfach wieder einfügen und die Verknüpfung passt wieder. Eventuell ist der Mapper sogar so nett und zieht beim Umbauen von Node auf Way alle Tags mit um. Dann passt es direkt wieder. Das Permanent ID Konzept taugt für mich garnicht, denn für die meisten Bildstöcke ist nur ein Tag dran. Und zwar das, was diesen Node als Bildstock auszeichnet. Ein start_date (sofern bekannt) wäre nicht eindeutig und Namen sind nur für die wenigsten Bildstöcke bekannt. Die UUID-Diskussion wurde schon oft gefuehrt, und es konnte meines Erachtens nie schluessig dargelegt werden, was die UUID genau sein soll. Eine UUID fuer die ganze Bachstrasse, oder eine fuer jeden Teil-Way? Wenn ich ein denkmalgeschuetztes Haus mappe und drin ist ein Restaurant, und ich gebe dem Way eine UUID, und spaeter zieht das Restaurant um auf die andere Strassenseite - woher weiss ich dann, ob ich die UUID mit umziehen muss (weil sie in einem Restaurantfuehrer verwendet wird) oder nicht (weil sie in einem Architekturfuehrer verwendet wird)? Aha, wir brauchen mehrere UUIDs pro Objekt, eine fuer jeden Aspekt... Und? http://wiki.openstreetmap.org/wiki/Proposed_Features/UUID#UUID_Tagging Gibt dann halt ein uuid:building für das Gebäude und ein uuid:amenity für das Restaurant. Entweder beidem am Way des Gebäudes oder das uuid:building am Gebäude und das uuid:amenity auf dem Node für das Restaurant. Und für meine Bildstöcke wäre uuid:historic das richtige Tag. Aus der Liste würde ich lediglich sowas wie uuid:operator ersatzlos streichen. Das muss in Chaos enden sobald jemand einen Operator mit UUID versehen will, der z.B. Deutschlandweit aktiv ist. Ich finde die Idee gut. Ich habe auch schon mehrfach darüber nachgedacht einfach eine eigene ID als Tag in die OSM-DB zu schreiben und mich dann selber um das Pflegen meines Tags zu kümmern. Ebenso könnte ich aber auch ein allgemeines uuid:*-Tag verwenden. Würde mein Problem auch lösen und wäre dann kein Spezialtag, das ich erfunden habe. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] LKW Mautinformationen
Hallo zusammen, ich arbeite für die Firma synyx, die sich darauf spezialisiert hat Softwarelösungen auf Basis von Opensource Komponenten zu entwickeln. Aktuell haben wir ein Projekt am Start, in dem Mautinformationen (für LKWs) benötigt werden, welche von OSM bereitgestellt werden sollen (diese sind eben noch nicht vorhanden). Aus diesem Grund würden wir gerne die mautpflichtigen Autobahnen und Bundesstraßen markieren und für die Community zur Verfügung stellen. Meine Kollegen und ich haben recherchiert und sind zu folgenden Vorschlag gekommen, wie wir das Kartenmaterial taggen würden: toll:hgv=yes (bzw. no, siehe Autobahnen) (ist kein neuer Tag, siehe http://wiki.openstreetmap.org/wiki/Key:toll) Autobahnen -- Da es ziemlich mühsam ist, alle Autobahnen zu taggen, würden wir hier den umgekehrten Weg gehen. Also alle Autobahnen, die keine Mautpflicht haben, erhalten toll:hgv=no. Bundesstraßen - Zum 1.8. werden auch einige Bundesstraßen mautplichtig. Da dies der kleinere Teil ist werden diese Straßen mit toll:hgv=yes getaggt. Die Informationen, welche Straßen dies betrifft haben wir vom Bundesamt für Güterverkehr genommen. Siehe http://www.bag.bund.de/SharedDocs/Kurzmeldungen/DE/2012/Maut_Bundesstra%C3%9Fen.html?nn=12502 Falls jemanden etwas einfällt, dies nicht zu tun, der soll sich bitte umgehend melden oder für immer schweigen :). Grüße Michael -- /** * Michael Herbold * Senior Developer * * synyx GmbH Co. KG * Open Source Solutions * Karlstr. 68 * 76137 Karlsruhe * * Telefon +49 721 203823-34 * Fax +49 721 203823-12 * E-Mailherb...@synyx.de * Web http://www.synyx.de * Blog http://blog.synyx.de * * Sitz der Gesellschaft: Karlsruhe * Registergericht: Mannheim * Handelsregisternummer: HRA 104793 * USt-IdNr.: DE249264296 * * Komplementärin: synyx Verwaltung GmbH * Sitz der Gesellschaft: Karlsruhe * Geschäftsführer: * Thomas Kraft, Markus Daniel, Joachim Arrasz * Registergericht: Mannheim * Handelsregisternummer: HRB 107250 */ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neuer OSMI-Layer fuer Lizenzwechsel-Resultate
Hallo, On 07/23/2012 12:43 PM, Hartmut Holzgraefe wrote: von der logischen Abstufung rot-orange-gelb her ist das zwar völlig OK und nachvollziehbar, aber mit der Sichtbarkeit von gelb hab ich so meine Probleme, insb. wenn es über highway=tertiary liegt ... :( Ja, das ist ein bisschen bloed, aber Du kannst ja voruebergehend oben am Transparenz-Schieber den Hintergrund wegblenden. Eigentlich wollt ich die Sachen, die gelb sind, ganz rauslassen, aber es gab Leute, die meinten, man sollte das noch sehen koennen. 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] Vorschlag Supersedes
Stefan Tiran wrote: Ein neuer Vorschlag: Wie wäre es damit, es so wie im Usenet zu machen? Wenn ein Objekt durch ein anderes ersetzt wird, auf das neue einen supersedes-Tag setzen, der als Wert die alte Objekt-ID hält. Das löst nicht das Problem Node wird durch Way ersetzt. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW Mautinformationen
Hallo Michael! Ich finde den Vorschlag gut, nur würde ich gerne wissen, was hgv heißen soll. Michael Herbold wrote Da es ziemlich mühsam ist, alle Autobahnen zu taggen, würden wir hier den umgekehrten Weg gehen. Also alle Autobahnen, die keine Mautpflicht haben, erhalten toll:hgv=no. An dieser Stelle werden sich garantiert ein paar Leute (inkl. mir und ich denke da nur an Martin) dran stoßen. Das hieße, dass ein nicht existierendes Tag eine Information ist. Das ist meiner Meinung nach nicht so gewollt, da nicht gepflegte Tags nicht bedeuten, dass dahinter eine Information liegt. Diese Schlussfolgerung kann aber durch dein vorgeschlagenes Vorgehen sehr leicht entstehen. Gruß, Philip -- View this message in context: http://gis.19327.n5.nabble.com/LKW-Mautinformationen-tp5717981p5717986.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] LKW Mautinformationen
Am 23.07.2012 12:53, schrieb Michael Herbold: Die Informationen, welche Straßen dies betrifft haben wir vom Bundesamt für Güterverkehr genommen. Siehe http://www.bag.bund.de/SharedDocs/Kurzmeldungen/DE/2012/Maut_Bundesstra%C3%9Fen.html?nn=12502 Mit der Lizenz sind wir etwas pingelig :-) deshalb kann es nicht schaden, eine explizite Erlaubnis vom Bund einzuholen, diese Daten in OSM ablegen zu dürfen. Das vorgeschlagene Tagging (hgv:toll=yes/no) ist IMHO in Ordnung. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Am 23.07.2012 12:38, schrieb Manuel Reimer: Beispiel: Ich habe für unseren Heimat- und Geschichtsverein eine Karte gebaut, auf der alle Bildstöcke, Wegkreuze, Kirchen und Sehenswürdigkeiten als kleine Pinnadeln gezeigt werden. Beim Anklicken der Pinnadel geht ein Popup mit kurzem Text und einem Foto auf. Die Verknüpfung zwischen Punkt (Hole ich aus der OSM-DB) und Text + Foto mache ich aktuell anhand der ID. Wenn sich die ID mal ändert, dann muss ich in meiner DB eine Änderung durchführen. Hätte ich nun UUIDs, dann könnte ich stattdessen eine von einem Mapper kaputtgemachte UUID einfach wieder einfügen und die Verknüpfung passt wieder. Eventuell ist der Mapper sogar so nett und zieht beim Umbauen von Node auf Way alle Tags mit um. Dann passt es direkt wieder. Ich fasse mal zusammen: mit OSM-ID musst du eingreifen, wenn das benötigte Objekt eine andere OSM-ID bekommt und bei UUID musst du eingreifen, wenn jemand das Objekt mit der UUID ändert. Wo ist der Vorteil der UUID? Das Permanent ID Konzept taugt für mich garnicht, denn für die meisten Bildstöcke ist nur ein Tag dran. Und zwar das, was diesen Node als Bildstock auszeichnet. Aber es ist doch immer ein Objekt an nahezu einer Koordinate, oder? Dann frag' halt die Overpass-API nach allen Bildstöcken in einer gewissen BBox. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorschlag Supersedes
Hi, On 07/23/2012 12:53 PM, Manuel Reimer wrote: Ein neuer Vorschlag: Wie wäre es damit, es so wie im Usenet zu machen? Wenn ein Objekt durch ein anderes ersetzt wird, auf das neue einen supersedes-Tag setzen, der als Wert die alte Objekt-ID hält. Das löst nicht das Problem Node wird durch Way ersetzt. Und loest nicht das Problem, dass der Mapper mehr Arbeit hat. Und loest nicht das Problem, dass der Mapper sich fragen muss, *was* denn jetzt superseded wird - wenn das Restaurant auf die andre Strassenseite zieht, ist das dann auch ein supersede, obwohl das alte Haus noch steht usw. 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] Permanente/stabile OSM IDs!
Hallo Georg, Am 23. Juli 2012 06:31 schrieb Georg Feddern o...@bavarianmallet.de: Am 23.07.2012 00:09, schrieb Stefan Keller: Grundsätzlich einverstanden. Deine Aussage sollte aber doch nicht solche Fälle sanktionieren, die ich oben erwähnt habe, bei denen der Mapper einen Node (wie z.B. eine Bushaltestelle, die vorher Teil eines Ways war) nur verschieben will! Da sollte JOSM unbedingt Hand bieten, dass bitte der Haltestellen-Node (mit ID und Haltestellen-Namen und allen Tags) erhalten bleibt und bitte ein neuer Node in den Way eingefügt wird und nicht - wie offenbar aktuell - der Node im Way erhalten wird und die Haltestelle eine neue Node-ID erhält. Warum soll JOSM insgesamt drei Objekte (H-node, way-node, way) verändern, nur um eine OSM-interne ID an den für irgendeinen Auswerter vermeintlich richtigen Ort zu plazieren, wenn es doch reicht, nur zwei Objekte (H-node, way-node-Tags) zu verändern? Wer sagt, dass die Haltestelle wichtiger ist als der node in der Straße - der (rein hypothetisch) ein Vermessungspunkt sein könnte? Du scheinst Objekte von OSM (Strukturen) höher zu gewichten als Objekte der der realen Welt. Die Sachlage ist so: Die Haltestelle hier http://www.openstreetmap.org/browse/node/1832873388 war vorhin ein Node zweier Ways: http://www.openstreetmap.org/browse/node/983813495/history Was der Mapper (bzw. JOSM) offensichtlich gemacht haben, ist, dass die Haltestelle neu erzeugt wurde. Die Absicht des Mappers ist und war aber eindeutig die Haltestelle von der Strassenmitte an die Seite zu verschieben. Das Verschieben soll aber auch funktionieren, wenn es um Parkbänke geht, die keinen Namen haben! Genau. Und bitte unter Beibehaltung der OSM ID - OSM und Nachnutzern zuliebe. Bei solchen Argumenten fällt mir irgendwie immer ein, das auch Koordinaten eindeutige IDs sind ... Diese IDs sind dann immer eindeutig ... und passende Objekte können auch in einem gewissen Suchradius gefunden werden. Die dann extern auf andere IDs gemappt werden können, so man unbedingt will. Stimmt: Koordinaten sind auch Identifikatoren - und darum verlieren ein Objekt genau diese identifizierendes Attribut wenn es verschoben wird. Daher gibt es IDs. Und wenn das OSM-Objekt dann verschoben wird, - stimmte entweder die vorherige Projekt-ID erst gar nicht (die Parkbank mit der Projekt-ID 123 musste sich an der Koordinate xyz befinden!) - oder das Projekt-Objekt wurde tatsächlich verschoben (neue Koordinate = externe Zuordnung anpassen!) Die Projekt-ID 123 bleibt in beiden Fällen hoffentlich erhalten, wenn das Objekt nur verschoben wird - die Kundennummer einer Adresskartei bleibt ja auch erhalten, wenn der Kunde eine andere Adresse bezieht. - oder es ist der ganz typische OSM-Fall: Der Mapper hat das OSM-Objekt komplett verändert (Projekt muss eh sein Objekt auch als OSM-Objekt wiederherstellen!) Ja; wo platt is is platt - da bleibt es dem Projekt nur noch zu cachen und zu kontrollieren, ob da wirklich in der Realität auch etwas platt gemacht wurde. Aber wir erwarten doch auch nicht, das Mapper sich für Sitzbänke und Briefkästen irgendwelche ref-Attribute ausdenken müssen - dazu braucht's m.E. Projekt-IDs, oder? Und was unterscheidet eine Projekt-ID von irgenwelchem ausgedachten ref-Attribut? Ausgezeichnete Frage: Es sind drei Dinge, die eine Projekt-ID von einem ref-Attribut unterscheiden: Eine Projekt-ID... 1. ist eine einzige ID, die für das Projekt eindeutig ist (ref ist oft erst mit network zusammen eindeutig - wenn überhaupt) 2. ist eine ID ist nicht sprechend und wird z.B. niemals Spaces enthalten (wie das mit A 533 der Fall ist) 3. steht für das OSM Objekt selber (sozusagen als Mini-UUID und als OSM-ID Ersatz) und ist (für OSM) nicht eine Referenz (ref) als Teil eines Ganzes Aber wie ich schon Frederik antwortete: Ich muss mir überlegen, ob eine Kombination von Attributen (name+ref+network) den gleichen Nutzen bringt wie eine Projekt-ID - für von Mappern ausgewählte Objekte - was lange nicht alle sind: Parkbänke, Einzelparkplätze, etc. z.B. haben weder Namen noch ein ref-Tag. LG, Stefan Am 23. Juli 2012 06:31 schrieb Georg Feddern o...@bavarianmallet.de: Moin, Am 23.07.2012 00:09, schrieb Stefan Keller: Am 22. Juli 2012 22:58 schrieb Frederik Ramm frede...@remote.org: Grundsätzlich einverstanden. Deine Aussage sollte aber doch nicht solche Fälle sanktionieren, die ich oben erwähnt habe, bei denen der Mapper einen Node (wie z.B. eine Bushaltestelle, die vorher Teil eines Ways war) nur verschieben will! Da sollte JOSM unbedingt Hand bieten, dass bitte der Haltestellen-Node (mit ID und Haltestellen-Namen und allen Tags) erhalten bleibt und bitte ein neuer Node in den Way eingefügt wird und nicht - wie offenbar aktuell - der Node im Way erhalten wird und die Haltestelle eine neue Node-ID erhält. Warum soll JOSM insgesamt drei Objekte (H-node, way-node, way) verändern, nur um eine OSM-interne ID an den für irgendeinen Auswerter vermeintlich
Re: [Talk-de] LKW Mautinformationen
Ich finde den Vorschlag gut, nur würde ich gerne wissen, was hgv heißen soll. Hgv: Heavy goods vehicle - OSM key fuer LKW (ich glaube ueber 3.5t) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW Mautinformationen
Ich bin mir nicht sicher, dass dieses einfache System funktioniert. toll:hgv bezieht sich hier auf ein spezifisches Maut-System in Deutschland. Das vorgeschlagene negativ-tagging waere auch nur in Deutschalnd korrekt. Ich sehe zwei Probleme: die internationale Komptbilitaet des vorschlagenen tagging-Systems ein moeglichen Konflikt mit lokalen Mautserhebungen, die nicht durch das generelle System abgedeckt sind. Was der LKW-Fahrer braucht, ist ein Verfahren, dass ihm sagt, wo er mit seiner generell bezahlten Deutschland-Maut durchfahren darf und wo nicht. Ob das geht, ohne das spezifische Mautsystem zusaetzlich zu taggen, ist mir nicht klar. 2012/7/23 Michael Herbold herb...@synyx.de Hallo zusammen, ich arbeite für die Firma synyx, die sich darauf spezialisiert hat Softwarelösungen auf Basis von Opensource Komponenten zu entwickeln. Aktuell haben wir ein Projekt am Start, in dem Mautinformationen (für LKWs) benötigt werden, welche von OSM bereitgestellt werden sollen (diese sind eben noch nicht vorhanden). Aus diesem Grund würden wir gerne die mautpflichtigen Autobahnen und Bundesstraßen markieren und für die Community zur Verfügung stellen. Meine Kollegen und ich haben recherchiert und sind zu folgenden Vorschlag gekommen, wie wir das Kartenmaterial taggen würden: toll:hgv=yes (bzw. no, siehe Autobahnen) (ist kein neuer Tag, siehe http://wiki.openstreetmap.org/wiki/Key:toll) Autobahnen -- Da es ziemlich mühsam ist, alle Autobahnen zu taggen, würden wir hier den umgekehrten Weg gehen. Also alle Autobahnen, die keine Mautpflicht haben, erhalten toll:hgv=no. Bundesstraßen - Zum 1.8. werden auch einige Bundesstraßen mautplichtig. Da dies der kleinere Teil ist werden diese Straßen mit toll:hgv=yes getaggt. Die Informationen, welche Straßen dies betrifft haben wir vom Bundesamt für Güterverkehr genommen. Siehe http://www.bag.bund.de/SharedDocs/Kurzmeldungen/DE/2012/Maut_Bundesstra%C3%9Fen.html?nn=12502 Falls jemanden etwas einfällt, dies nicht zu tun, der soll sich bitte umgehend melden oder für immer schweigen :). Grüße Michael -- /** * Michael Herbold * Senior Developer * * synyx GmbH Co. KG * Open Source Solutions * Karlstr. 68 * 76137 Karlsruhe * * Telefon +49 721 203823-34 * Fax +49 721 203823-12 * E-Mailherb...@synyx.de * Web http://www.synyx.de * Blog http://blog.synyx.de * * Sitz der Gesellschaft: Karlsruhe * Registergericht: Mannheim * Handelsregisternummer: HRA 104793 * USt-IdNr.: DE249264296 * * Komplementärin: synyx Verwaltung GmbH * Sitz der Gesellschaft: Karlsruhe * Geschäftsführer: * Thomas Kraft, Markus Daniel, Joachim Arrasz * Registergericht: Mannheim * Handelsregisternummer: HRB 107250 */ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW Mautinformationen
On Mon, Jul 23, 2012 at 12:53:05PM +0200, Michael Herbold wrote: ich arbeite für die Firma synyx, die sich darauf spezialisiert hat Softwarelösungen auf Basis von Opensource Komponenten zu entwickeln. Aktuell haben wir ein Projekt am Start, in dem Mautinformationen (für LKWs) benötigt werden, welche von OSM bereitgestellt werden sollen (diese sind eben noch nicht vorhanden). Aus diesem Grund würden wir gerne die mautpflichtigen Autobahnen und Bundesstraßen markieren und für die Community zur Verfügung stellen. Da gabs schonmal ein Projekt bei dem jemand alle diese Daten für OSM gespendet hat. Weiss nicht, was daraus geworden ist... Meine Kollegen und ich haben recherchiert und sind zu folgenden Vorschlag gekommen, wie wir das Kartenmaterial taggen würden: toll:hgv=yes (bzw. no, siehe Autobahnen) (ist kein neuer Tag, siehe http://wiki.openstreetmap.org/wiki/Key:toll) Autobahnen -- Da es ziemlich mühsam ist, alle Autobahnen zu taggen, würden wir hier den umgekehrten Weg gehen. Also alle Autobahnen, die keine Mautpflicht haben, erhalten toll:hgv=no. Bundesstraßen - Zum 1.8. werden auch einige Bundesstraßen mautplichtig. Da dies der kleinere Teil ist werden diese Straßen mit toll:hgv=yes getaggt. Es ist keine gute Idee, verschiedene Defaults für toll:hgv zu benutzen. Das ist a) verwirrend, weil kontextabhängig und b) geht das jetzt von der Situation in Deutschland aus. Was ist, wenn in Frankreich nur wenige Autobahnen Maut haben? Soll dann in Frankreich eine andere Tagging-Regel gelten? Da die allermeisten Straßen dieser Welt keine Maut erfordern, sollte der Default auch für alle Straßen no sein. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW Mautinformationen
2012/7/23 Michael Herbold herb...@synyx.de Hallo zusammen, ich arbeite für die Firma synyx, die sich darauf spezialisiert hat Softwarelösungen auf Basis von Opensource Komponenten zu entwickeln. Aktuell haben wir ein Projekt am Start, in dem Mautinformationen (für LKWs) benötigt werden, welche von OSM bereitgestellt werden sollen (diese sind eben noch nicht vorhanden). Aus diesem Grund würden wir gerne die mautpflichtigen Autobahnen und Bundesstraßen markieren und für die Community zur Verfügung stellen. Uns wurden schon 2010 die Mautdaten für das damalige Autobahnnetz gespendet: http://wiki.openstreetmap.org/wiki/Mautdaten Bisher wurden die Daten aber leider noch nicht eingepflegt. Ich hatte mir ursprünglich vorgenommen, mich nach dem Lizenzwechsel (+ ein paar Wochen zum ggf. Lückenschließen) damit zu beschäftigen. Wobei mir bisher nicht klar ist, wie man mit Shapefiles umgeht... toll:hgv=yes (bzw. no, siehe Autobahnen) (ist kein neuer Tag, siehe http://wiki.openstreetmap.org/wiki/Key:toll) HGV steht aber für Fahrzeuge ab 3,5 Tonnen; die deutsche LKW-Maut gilt aber erst für Fahrzeuge ab 12 Tonnen. Eventuell sollte man über einen anderen Wert nachdenken - z.B. LGV. Autobahnen -- Da es ziemlich mühsam ist, alle Autobahnen zu taggen, würden wir hier den umgekehrten Weg gehen. Also alle Autobahnen, die keine Mautpflicht haben, erhalten toll:hgv=no. Bitte nicht. Das widerspricht dem sonst in OSM üblichen Vorgehen. Und wenn man weiß, wie man es machen muss, ist das jetzt auch nicht so mühsam. Wenn man mir die nötigen Daten zur Verfügung stellt, würde ich mich auch bereit erklären, das zu übernehmen. Bundesstraßen - Zum 1.8. werden auch einige Bundesstraßen mautplichtig. Da dies der kleinere Teil ist werden diese Straßen mit toll:hgv=yes getaggt. Auf der Seite der Mauttabelle sind die neuen Bundesstraßen auch als Shapefile hinterlegt: http://www.mauttabelle.de/maut.html Vlt. könnte man da mal die Nutzungsmöglichkeit abklären. Dann gibt es da noch Spezialfälle: Z.B. die A6: http://www.mauttabelle.de/maut_120a.html#a6 Die ist als Bundesautobahn eigentlich auf ganzer Strecke Mautpflichtig, aber aus historischen Gründen um Saarbrücken herum mautfrei. Das wird dadurch realisiert, dass man die Länge der mautpflichtigen Abschnitte einfach mit 0 km ansetzt. Soll man das gesondert erfassen oder einfach als nicht mautpflichtige Strecke? Und dann bin ich der Meinung, dass man mautpflichtige Strecken ab dem letzten Punkt, an dem man noch die Fahrt auf der mautpflichtigen Strecke vermeiden kann, erfassen sollte. Also auch Autobahnauffahrten oder Autobahnzubringer. Nur ist das bei der LKW-Maut dann ja ein Unterschied, ob man jetzt auf der eigentlichen Autobahn für jeden gefahrenen km zahlt, oder ob man nur an einer Stelle ist, an der man das befahren von kostenpflichtigen Abschnitten nur nicht mehr legal vermeiden kann. Unterschiedlich erfasen und wenn ja wie? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Hallo Peter Am 23. Juli 2012 09:02 schrieb Peter Wendorff wendo...@uni-paderborn.de: Am 22.07.2012 23:34, schrieb Stefan Keller: Hallo Henning (aighes) Am 22. Juli 2012 23:05 schrieb aighes o...@aighes.de: Am 22.07.2012 22:45, schrieb Stefan Keller: Am 22. Juli 2012 22:14 schrieb aighes o...@aighes.de: Oder wenn jemand das Objekt nun anderweitig nutzt. Bspw. Straße - Gebäude. Dann hat auf einmal das Gebäude die ref der Straße. Verstehe ich nicht. Jedenfalls bin ich mit dir gleicher Meinung, dass OSM nicht eine Datenbank für alle sein kann und einfach vollgestopft werden soll mit Tags, die von externen Projekten kommen. Der einzige Tag den ich vorschlage ist diese eine Projekt_ID. Nein. Die ID hilft keinem bei der sicheren Zuordnung. Es hat keinen Vorteil gegenüber der normalen Objekt-ID. Doch: Es ist permanent/stabil/eindeutig (falls einem die OSM ID nicht genügt). Bsp: Restaurant als Node eingetragen mit Projekt-ID. Nun wird aus dem Restaurant eine Fläche und der Node wird bspw. eine Parkbank und behält die Projekt-ID. Der normale Mapper wird sich darum nicht kümmern, weil es ihm nichts sagt und er auch nicht weiß, ob die ID nun zum Node an sich gehört, oder zu dem Objekt Restaurant. Das mit dem Verschieben von Node zu Fläche habe ich oben beantwortet. Wenn ein Mapper aus einen Restaurant als Node eine Parkbank macht, dann stimmte entweder tatsächlich vorher etwas nicht mit der Realität überein (und die externe Datenank registriert das) oder mit dem Mapper Mit dem Mapper stimmt alles, denn OSM-IDs sind Schall und Rauch und nur zur akuten Verwendung zwischen Objekten stabil - und an der Stelle hat der Mapper definitiv nichts falsch gemacht. Ja, schon Frederik hat in die Richtung argumentiert. Wie ich ganz zu Beginn schon gesagt habe: Entweder das Projekt kann mit unstabilen OSM-IDs leben - oder es muss sich was einfallen lassen. Der betreffende Mapper ist eben vielleicht kein Datenbank-Fetischist, weiß unter Umständen nicht mal, was eine ID ist, und braucht das auch nicht wissen. Er muss tatsächlich möglichst wenig von IDs mitbekommen. Nur eines kann und muss er wissen: Ändern ist nicht dasselbe wie Löschen und wieder einfügen! Wenn jemand in einer Adresskartei einen Kundennamen ändert, dann löscht er auch nicht den ganzen Kunden um ihn gleich nochmals komplett neu zu erfassen. :- Will anständigerweise sagen, er war sich seiner unbedarften Handlung nicht bewusst, und das Projekt ist so nett (zu OSM), erzeugt das Restaurant wieder (mit seiner Projekt-ID) und löscht die Projekt-ID beim Parkbank. Das Projekt - egal ob du damit jetzt den OSM-Server oder einen beliebigen Editor meinst, weiß aber nunmal gar nicht, ob der mapper damit wirklich das Objekt verändert hat. Mit Projekt meine ich z.B. eine Parkbänke- oder eine Einzelparkplatz-Datenbank. Die vergibt nun solche Projekt-IDs jedem OSM-Objekt, das es interessiert als stabile Alternative zur OSM-ID. Vielleicht ist die Bushaltestelle gar nicht durch ein anderes Objekt ersetzt worden, sondern nur durch ein neues Taggingschema, das die Software noch nicht kennt - deshalb aber ja nicht verboten ist. Verboten ist nichts - nur bitte die Arbeit anderer (also hier u.a. die Projekt-ID) stehen lassen (ausser die Bushaltestelle wurde in der Realität aufgehoben). Deine Lösung erfordert also entweder festgelegte Tagging-Regeln, damit solche Ersetzungsregeln auch nur ansatzweise funktionieren (denn auch ein nachträgliches hinzufügen/hinterherziehen neuer Taggingvarianten würde sonst ja das brechen von IDs nicht verhindern), oder aber es funktioniert schlichtweg nicht. Meine Lösung umfasst alle Eigenschaften des Overpass-Permanent-ID-Konzepts, grenzt es ein, damit der Tag als ID erkenntlich wird und weitet es aus auf sämtliche OSM-Objekte. Dass sich ein Objekt in zwei jeweils nur einzelne Aspekte dessen beschreibende teilt, ist damit übrigens auch noch nicht gelöst. Sinnvoller wäre es, bspw. über die OverpassAPI nach einem Restaurant mit dem Namen xyz in der BBox... zu fragen. Ok: Restaurants haben Namen (wenn auch kaum eindeutige), Parkbänke leider kaum. Daher ist die Idee der kombinierten Tags unzureichend. Ich mappe am Montag vier Bänke auf dem Marktplatz. Eine davon (!) bekommt am Dienstag eine ID nach deinem Schema vom Schlafbank-projekt ;). Ich komme Freitags wieder vorbei und da stehen immer noch vier Parkbänke, aber nicht an der gleichen Stelle. Es ist definitiv nicht zu erkennen, ob die Bänke jetzt verschoben worden sind, oder ob das andere Bänke sind. Nun kommen wir der Sache näher (interessantes Projekt: Schlafbänke :-): Du musst dich als reiner OSM-Mapper in diesem Falle um nichts kümmern - nur die Bänke erfassen (es könnten auch Einzelparkplätze sein). Das Schlafbank-Projekt (vgl. Frederiks Vorschlag der externen DB oben) hat am Montag erkannt, dass vier Bänke erfasst wurden und hat eines davon in seine DB übernommen und in OSM mit der ID markiert und identifiziert
Re: [Talk-de] LKW Mautinformationen
Am 23.07.2012 14:15, schrieb Robert S.: Und dann bin ich der Meinung, dass man mautpflichtige Strecken ab dem letzten Punkt, an dem man noch die Fahrt auf der mautpflichtigen Strecke vermeiden kann, erfassen sollte. Also auch Autobahnauffahrten oder Autobahnzubringer. Nur ist das bei der LKW-Maut dann ja ein Unterschied, ob man jetzt auf der eigentlichen Autobahn für jeden gefahrenen km zahlt, oder ob man nur an einer Stelle ist, an der man das befahren von kostenpflichtigen Abschnitten nur nicht mehr legal vermeiden kann. Unterschiedlich erfasen und wenn ja wie? Das ist vergleichbar mit dem Erfassen von noexit=yes an Sackgassen die in einer Wendeplatte Enden. Ich bin strikt dagegen. (noexit am letzten Node einer Sackgasse ohne Wendeplatte finde ich gut, aber das ist ein anderes Thema.) Dass man diese Zubringer im Fall der Fälle meiden sollte, lässt sich bei Bedarf sehr einfach berechnen. Ein Navi das auf keine Mautstraßen eingestellt ist, wird den Zubringer einfach nicht nutzen, da es damit keine passende Route zustande bekommt. Du hast das wesentliche Argument schon genannt: Wenn man auswerten will, wie viele km mautpflichtiger Strecke man fährt, dann sollte das auch zu der Deklaration passen, also nur dort getagged sein wo es auch so ist. Gruß, Bernd -- In Binärzahlen zu zählen geht genauso wie in Dezimalzahlen zählen, nur daß man dafür nur die Daumen braucht. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW Mautinformationen
Hallo Michael, On 23.07.2012 12:53, Michael Herbold wrote: Hallo zusammen, ich arbeite für die Firma synyx, die sich darauf spezialisiert hat Softwarelösungen auf Basis von Opensource Komponenten zu entwickeln. Aktuell haben wir ein Projekt am Start, in dem Mautinformationen (für LKWs) benötigt werden, welche von OSM bereitgestellt werden sollen (diese sind eben noch nicht vorhanden). Aus diesem Grund würden wir gerne die mautpflichtigen Autobahnen und Bundesstraßen markieren und für die Community zur Verfügung stellen. Vor 2 Jahren wurden die (damals) aktuellen Daten bereits für OSM zur Verfügung gestellt. Ich habe sie daraufhin in das Shapefile-Format konvertiert und es gibt auch einen WMS-Layer, der die Daten visualisiert. Da sich aber niemand fand, der sich um ein sinnvolles Tagging Gedanken machen wollte, gab es letztendlich keinen Import. Nachzulesen ist der letzte Stand auf http://wiki.openstreetmap.org/wiki/Mautdaten Es ist schön zu sehen das es Interesse an Mautinfos gibt. Vielleicht hilft ja die Vorarbeit den Aufwand jetzt zu reduzieren. Lars ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW Mautinformationen
HGV steht aber für Fahrzeuge ab 3,5 Tonnen; die deutsche LKW-Maut gilt aber erst für Fahrzeuge ab 12 Tonnen. Eventuell sollte man über einen anderen Wert nachdenken - z.B. LGV. Auch LGV ist nicht so gut, denn in GB ist HGV (Heavy goods vehicle) durch LGV (Large goods vehicle) ersetzt worden, immer mit derselben Grenze von 3.5 metrischen Tonnen (https://en.wikipedia.org/wiki/Large_goods_vehicle) Volker ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW Mautinformationen
2012/7/23 Bernd Wurst be...@bwurst.org Am 23.07.2012 14:15, schrieb Robert S.: Und dann bin ich der Meinung, dass man mautpflichtige Strecken ab dem letzten Punkt, an dem man noch die Fahrt auf der mautpflichtigen Strecke vermeiden kann, erfassen sollte. Also auch Autobahnauffahrten oder Autobahnzubringer. Nur ist das bei der LKW-Maut dann ja ein Unterschied, ob man jetzt auf der eigentlichen Autobahn für jeden gefahrenen km zahlt, oder ob man nur an einer Stelle ist, an der man das befahren von kostenpflichtigen Abschnitten nur nicht mehr legal vermeiden kann. Unterschiedlich erfasen und wenn ja wie? Das ist vergleichbar mit dem Erfassen von noexit=yes an Sackgassen die in einer Wendeplatte Enden. Ich bin strikt dagegen. (noexit am letzten Node einer Sackgasse ohne Wendeplatte finde ich gut, aber das ist ein anderes Thema.) In der mapping-Praxis dürfte noexit=yes überall dort erfasst sein, wo auch das entsprechende StVO-Schild steht - unabhängig von einer Wendemöglichkeit. Analog dazu habe ich auch schon an einem langen Autobahnzubringer ein Schild LKW-Maut in 10 km gesehen. Dass man diese Zubringer im Fall der Fälle meiden sollte, lässt sich bei Bedarf sehr einfach berechnen. Berechnen, berechnen Entschuldigung, aber ich bin der Meinung, dass man OSM-Daten auch ohne Informatik-Diplom auswerten können sollte. Ein Navi das auf keine Mautstraßen eingestellt ist, wird den Zubringer einfach nicht nutzen, da es damit keine passende Route zustande bekommt. Wir mappen ja nicht (nur) für die Navis. Du hast das wesentliche Argument schon genannt: Wenn man auswerten will, wie viele km mautpflichtiger Strecke man fährt, dann sollte das auch zu der Deklaration passen, also nur dort getagged sein wo es auch so ist. Deshalb ja die Frage nach der unterschiedlichen Erfassung. Wenn man die Strecken, auf denen tatsächlich die km-Maut erhoben wird mit 'toll:hgv=yes' erfasst und die abhängigen Zubringer mit einem anderen Wert, kann man die angesprochene Auswertung trotzdem problemlos machen, ohne die Zubringer außer Acht zu lassen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Warnungen beim Erzeugen einer Navit Karte (Österreich)
Ich leite das mal an talk-at weiter... Rainer Dorsch schrieb: Hallo, hier die Warnungen für die Österreich: turn restrictions: OSM Warning:http://www.openstreetmap.org/browse/relation/92427 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/223509 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/241646 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/278859 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/278860 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/278862 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/302959 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/311734 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/535236 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1318143 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1476938 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1485409 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1492801 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1506472 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/1527515 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1683246 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1696176 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1696177 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1733647 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/1779147 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1790945 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1857345 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1866773 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/2090704 turn restriction: multiple via member OSM Warning:http://www.openstreetmap.org/browse/relation/2130728 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1389144 turn restriction: from member not found OSM Warning:http://www.openstreetmap.org/browse/relation/1389152 turn restriction: from member not found OSM Warning:http://www.openstreetmap.org/browse/relation/2102804 turn restriction: to member not found OSM Warning:http://www.openstreetmap.org/browse/relation/2182619 turn restriction: from member not found polygon Warnungen: OSM Warning:http://www.openstreetmap.org/browse/way/34495781 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/44840922 Broken polygon, area is 0 OSM Warning:http://www.openstreetmap.org/browse/way/51852521 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/72765511 Broken polygon, area is 0 OSM Warning:http://www.openstreetmap.org/browse/way/101693601 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/116909398 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/123449371 Broken polygon, area is 0 OSM Warning:http://www.openstreetmap.org/browse/way/151237729 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/162979331 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/165962199 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/169695178 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/171490446 Broken polygon, less than 3 points defined ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
On 23.07.2012 14:22, Stefan Keller wrote: Er muss tatsächlich möglichst wenig von IDs mitbekommen. Nur eines kann und muss er wissen: Ändern ist nicht dasselbe wie Löschen und wieder einfügen! Wenn jemand in einer Adresskartei einen Kundennamen ändert, dann löscht er auch nicht den ganzen Kunden um ihn gleich nochmals komplett neu zu erfassen. Der Vergleich mit einer Kundendatenbank hinkt. Gibt es keine Referenz per interner ID von und zu einem Kundensatz, dann kann dieser problemlos gelöscht und neu angelegt werden. Wenn aber die Kundendaten über eine interne ID noch mit Bestelldaten verknüpft sind, dann kann der Kundendatensatz nicht gelöscht werden. Vergleichbares ist bei den hier diskutierten Beispielen in OSM nicht möglich, da die Verknüpfung in der externen Anwendungsdatenbank realisiert ist. Der Mapper soll nun natürlich gemäss seiner Wahrnehmung der Realität entscheiden, was nun mit den Bänken geschehen sein könnte: Entscheidet er sich dafür, dass sie verschoben wurden, soll er das mit den vier Bänken tun (unter Beibehaltung der Projekt-ID bei der einen). Meint er, das seien vier brandneue, löscht er die vier (inkl. Projekt-ID) und erfasst vier neue (ohne Projekt-ID). Das Schlafbank-Projekt kriegt ja beides mit und muss reagieren. Nein, der gemeine Mapper nimmt die alten Bänke, verschiebt sie, ändert deren OSM-Tags und fasst deine Projekt-ID dabei nicht an. Er tut OSM damit was Gutes, weil er 4 OSM-IDs spart. Oder er macht sich Gedanken über diese Projekt-ID, verliert Zeit mit der Suche nach deren Bedeutung und dem Umgang mit ihr, ist verunsichert und lässt alles beim Alten, schliesslich will er ja nichts kaputt machen. Beides ist sicher nicht im Sinne des Schlafbankprojekts. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW Mautinformationen
Am 23.07.2012 13:00, schrieb Philip Gillißen: Hallo Michael! Ich finde den Vorschlag gut, nur würde ich gerne wissen, was hgv heißen soll. Kommt aus dem Englischen Raum. International eher unter LGV (Large Goods Vehicle) bekannt. Wird für Fahrzeuge genommen, welche unter die Kategorie N2 und N3 der EU fallen (somit Fahrzeuge zur Güterbeförderung über 3,5t bis 12t und über 12t). Michael Herbold wrote Da es ziemlich mühsam ist, alle Autobahnen zu taggen, würden wir hier den umgekehrten Weg gehen. Also alle Autobahnen, die keine Mautpflicht haben, erhalten toll:hgv=no. An dieser Stelle werden sich garantiert ein paar Leute (inkl. mir und ich denke da nur an Martin) dran stoßen. Das hieße, dass ein nicht existierendes Tag eine Information ist. Das ist meiner Meinung nach nicht so gewollt, da nicht gepflegte Tags nicht bedeuten, dass dahinter eine Information liegt. Diese Schlussfolgerung kann aber durch dein vorgeschlagenes Vorgehen sehr leicht entstehen. Es wäre nicht der erste Tag, welcher standardisiert auf yes gesetzt wird. (auf der Autobahn z.b. auch oneway), falls ich deine Kritik richtig verstanden habe. Auf jeden Fall wird nichts beschädigt, wenn auf eine mautfreie Autobahn toll:hgv=no gesetzt wird. Und alle die es anders wollen, setzen auf die mautbehafteten Autobahnen ein toll:hgv=yes. Die eine Methode schließt die andere ja nicht aus. LG Jimmy ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neuer OSMI-Layer fuer Lizenzwechsel-Resultate
Frederik Ramm frede...@remote.org wrote: Ja, das ist ein bisschen bloed, aber Du kannst ja voruebergehend oben am Transparenz-Schieber den Hintergrund wegblenden. Eigentlich wollt ich die Sachen, die gelb sind, ganz rauslassen, aber es gab Leute, die meinten, man sollte das noch sehen koennen. Na ja sind die nicht grün? Ich meine wenn jemand einen solchen Weg in den Fingern hatte, dann ist der doch meist wieder OK oder? Sven -- If you can spend five minutes on the Internet and do not run Linux, you're a genius. (Dirk Hohndel) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Am 23.07.2012 13:34, schrieb Stefan Keller: Hallo Georg, Am 23. Juli 2012 06:31 schrieb Georg Feddern o...@bavarianmallet.de: Und was unterscheidet eine Projekt-ID von irgenwelchem ausgedachten ref-Attribut? Ausgezeichnete Frage: Es sind drei Dinge, die eine Projekt-ID von einem ref-Attribut unterscheiden: Eine Projekt-ID... 1. ist eine einzige ID, die für das Projekt eindeutig ist (ref ist oft erst mit network zusammen eindeutig - wenn überhaupt) eine Projekt-ID lässt sich dagegen nicht osm-intern z.B. über ein network-Tag überprüfen, sondern nur mithilfe einer sonstwo verstreuten Datenbank des betreffenden Projekts. Ohne dieser Datenbank ist sie genausowenig eindeutig. 2. ist eine ID ist nicht sprechend und wird z.B. niemals Spaces enthalten (wie das mit A 533 der Fall ist) was hat das jetzt damit zu tun? abgesehen davon, dass ich durchaus in meinem Projekt IDs mit Spaces erzeugen könnte; nicht besonders gut les- aber machbar. 3. steht für das OSM Objekt selber (sozusagen als Mini-UUID und als OSM-ID Ersatz) und ist (für OSM) nicht eine Referenz (ref) als Teil eines Ganzes Aber wie ich schon Frederik antwortete: Ich muss mir überlegen, ob eine Kombination von Attributen (name+ref+network) den gleichen Nutzen bringt wie eine Projekt-ID - für von Mappern ausgewählte Objekte - was lange nicht alle sind: Parkbänke, Einzelparkplätze, etc. z.B. haben weder Namen noch ein ref-Tag. amenity=bench + in_bbox() amenity=parking_slot (oder wie auch immer da jetzt der aktuelle Stand ist) + has_coordinate(lat, lon) wie jemand anders ja schon festgestellt hat, ist die Koordinate durchaus auch eine ID. Wenn ich die Parkplätze untereinander unterscheiden will, sollte ich vielleicht geometrische abfragen innerhalb des Gesamtparkplatzes (amenity=parking) darauf ausführen, so dass ich sowas formulieren kann wie: amenity=parking_slot at [amenity=parking, parking=surface, in_bbox()] [3rd-row, 42nd column]. Ob das aber wirklich noch jemand machen will, ohne sich die entsprechenden Dinger lokal zu speichern... Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW Mautinformationen
Am 23.07.2012 13:46, schrieb Volker Schmidt: Was der LKW-Fahrer braucht, ist ein Verfahren, dass ihm sagt, wo er mit seiner generell bezahlten Deutschland-Maut durchfahren darf und wo nicht. Ob das geht, ohne das spezifische Mautsystem zusaetzlich zu taggen, ist mir nicht klar. Habe mich jetzt ein bisschen über das deutsche Mautsystem für Fahrzeuge über 12t informiert. Nebenbei, da wäre z.b. ein toll:N3=yes vielleicht passender, denn bei hgv (als N2 und N3) sind ja auch Fahrzeug von 3,5 bis 12t eingeschlossen. Welche abweichenden Mautsysteme gibt es in Deutschland? Ich konnte nur das Eine finden. LG Jimmy ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW Mautinformationen
Am 23.07.2012 14:15, schrieb Robert S.: toll:hgv=yes (bzw. no, siehe Autobahnen) (ist kein neuer Tag, siehe http://wiki.openstreetmap.org/wiki/Key:toll) HGV steht aber für Fahrzeuge ab 3,5 Tonnen; die deutsche LKW-Maut gilt aber erst für Fahrzeuge ab 12 Tonnen. Eventuell sollte man über einen anderen Wert nachdenken - z.B. LGV. Autobahnen LGV wäre der selbe Fehler. Da ich es jetzt zum wiederholten Male anspreche, habe ich die Richtline rausgesucht (2001/116/EG) [1] Hier gäbe es die Einteilung (im Anhang II auf Seite 39): 3,5t bis 12t: Klasse N2 über 12t: Klasse N3 Somit mein Vorschlag: toll:N3=* LG Jimmy ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW Mautinformationen
Hallo, erst mal vielen vielen Dank für das zahlreiche und konstruktive Feedback. Wir haben heute früh schon angefangen, die Strecken entsprechend zu taggen (siehe http://www.openstreetmap.org/user/synyx/edits). Wie Robert S. korrekt bemerkt hat ist toll:hgv=yes nicht korrekt, da die Maut erst ab 12 Tonnen gilt. Den Vorschlag toll:N3=yes finden wir gut und würden dies auch an den bereits erstellen Tags anpassen (thx @ jimmy für den Vorschlag). Die Problematik mit den impliziten Informationen ist uns bewusst. Prinzipiell haben wir kein Problem damit, dass mautpflichtige Autobahnen mit toll:N3=yes getaggt werden. Wie Jimmy schrieb, schliesst das eine das andere nicht aus. Wir haben bislang eben nur die mautfreien Teile getaggt. Ist es denn überhaupt gewollt, alle anderen Stelle mit yes zu taggen? Dies würde dazu führen, dass wirklich (fast) jedes Autobahnstück in Deutschland den Tag erhalten würde. Weiterhin würden wir die entsprechenden Wiki Seiten bezüglich dem Thema Maut ergänzen, damit die oben genannte Information schriftlich festgehalten und nachvollziehbar ist. Bezüglich der Lizenz sehen wir keine Probleme, da das Tagging auf Basis von Gesetzen erfolgt, dessen Text öffentlich verfügbar ist (siehe http://www.mauttabelle.de/faq.html#wog). Vielen Dank nochmals für die Rückmeldungen. Grüße Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Moin! Am 22.07.2012 22:58, schrieb Frederik Ramm: Hallo, ich bin der Ansicht, das OSM-IDs eine 100% OSM-interne Sache sind, auf die sich niemand sonst verlassen darf, weil dies die Handlungsmoeglichkeiten bei OSM einschraenkt. +1 Wenn ich ein denkmalgeschuetztes Haus mappe und drin ist ein Restaurant, und ich gebe dem Way eine UUID, und spaeter zieht das Restaurant um auf die andere Strassenseite - woher weiss ich dann, ob ich die UUID mit umziehen muss (weil sie in einem Restaurantfuehrer verwendet wird) oder nicht (weil sie in einem Architekturfuehrer verwendet wird)? Aha, wir brauchen mehrere UUIDs pro Objekt, eine fuer jeden Aspekt... Die Unklarheit der Zuordnung ist allerdings kein spezifisches Problem der UUIDs, sondern tritt bei allen Tags (name, height, url, ...) auf. Selbst wenn ein Mensch die Zuordnung meist richtig macht, kann eine Software das in der Regel nicht. Nur wenn man generell Gebäude und Gebäudenutzer als getrennte OSM-Objekte anlegt, gibt es solch Probleme nicht. Laut Overpass's Permanent ID könnte die Lösung eine eindeutige Eigenschaft des Objekts sein, typischerweise eine Kombination von Tags. Als Beispiel wird eine Relation mit den Tags network=BAB und ref=A 516 herangezogen. Ohne eine eindeutige Kombination aus name, ref, network, etc. wird es schwierig. Bei der A 516 wird es wohl funktionieren, die B 1 ist schon schwieriger, bei Bahnstrecken oder anderen ausgedehnten Objekten ohne ref wird es oft unmöglich. Was aber eine gute Idee waere: Man baut eine externe Datenbank als Interface zwischen der Oeffentlichkeit und OSM auf. Im Gegensatz zur reinen Verwendung von Overpass-IDs rund um die Welt hat dieses Vorgehen den Vorteil, dass alle Links in der Datenbank regelmaessig automatisiert ueberprueft werden koennen: Sind sie noch gueltig? Zeigen sie noch auf genau 1 Objekt, oder mittlerweile auf 0 oder 2? Das setzt voraus, das es zu jedem realen Objekt genau ein OSM-Objekt gibt. Vor- und Nachteile hatten wir gerade im Thread Relationen aus der Sicht der Auswertung - Segen oder Fluch?? diskutiert. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Hallo Henning/aighes Am 23. Juli 2012 13:16 schrieb aighes o...@aighes.de: Am 23.07.2012 12:38, schrieb Manuel Reimer: Beispiel: Ich habe für unseren Heimat- und Geschichtsverein eine Karte gebaut, auf der alle Bildstöcke, Wegkreuze, Kirchen und Sehenswürdigkeiten als kleine Pinnadeln gezeigt werden. Beim Anklicken der Pinnadel geht ein Popup mit kurzem Text und einem Foto auf. Die Verknüpfung zwischen Punkt (Hole ich aus der OSM-DB) und Text + Foto mache ich aktuell anhand der ID. Wenn sich die ID mal ändert, dann muss ich in meiner DB eine Änderung durchführen. Hätte ich nun UUIDs, dann könnte ich stattdessen eine von einem Mapper kaputtgemachte UUID einfach wieder einfügen und die Verknüpfung passt wieder. Eventuell ist der Mapper sogar so nett und zieht beim Umbauen von Node auf Way alle Tags mit um. Dann passt es direkt wieder. Ich fasse mal zusammen: mit OSM-ID musst du eingreifen, wenn das benötigte Objekt eine andere OSM-ID bekommt und bei UUID musst du eingreifen, wenn jemand das Objekt mit der UUID ändert. Wo ist der Vorteil der UUID? Folgendes fehlt in deiner Zusammenfassung: Mit der OSM-IDs ist die Gefahr grösser als mit der UUID, dass das Projekt das Objekt verliert (da es einer gelöscht und mit denselben Tags neu erstellt hat). Wenn jemand das Objekt ändert, dann muss das Projekt so oder so überprüfen. Daher die UUID, bzw. die Projekt-ID Das Permanent ID Konzept taugt für mich garnicht, denn für die meisten Bildstöcke ist nur ein Tag dran. Und zwar das, was diesen Node als Bildstock auszeichnet. Das ist genau der Grund, der für die Projekt-ID spricht. Aber es ist doch immer ein Objekt an nahezu einer Koordinate, oder? Dann frag' halt die Overpass-API nach allen Bildstöcken in einer gewissen BBox. Eine BBox taugt nicht als Identifikator. Wenn das Objekt verschoben wurde, dann ist es weg, ausserhalb der BBOX. LG, Stefan Am 23. Juli 2012 13:16 schrieb aighes o...@aighes.de: Am 23.07.2012 12:38, schrieb Manuel Reimer: Beispiel: Ich habe für unseren Heimat- und Geschichtsverein eine Karte gebaut, auf der alle Bildstöcke, Wegkreuze, Kirchen und Sehenswürdigkeiten als kleine Pinnadeln gezeigt werden. Beim Anklicken der Pinnadel geht ein Popup mit kurzem Text und einem Foto auf. Die Verknüpfung zwischen Punkt (Hole ich aus der OSM-DB) und Text + Foto mache ich aktuell anhand der ID. Wenn sich die ID mal ändert, dann muss ich in meiner DB eine Änderung durchführen. Hätte ich nun UUIDs, dann könnte ich stattdessen eine von einem Mapper kaputtgemachte UUID einfach wieder einfügen und die Verknüpfung passt wieder. Eventuell ist der Mapper sogar so nett und zieht beim Umbauen von Node auf Way alle Tags mit um. Dann passt es direkt wieder. Ich fasse mal zusammen: mit OSM-ID musst du eingreifen, wenn das benötigte Objekt eine andere OSM-ID bekommt und bei UUID musst du eingreifen, wenn jemand das Objekt mit der UUID ändert. Wo ist der Vorteil der UUID? Das Permanent ID Konzept taugt für mich garnicht, denn für die meisten Bildstöcke ist nur ein Tag dran. Und zwar das, was diesen Node als Bildstock auszeichnet. Aber es ist doch immer ein Objekt an nahezu einer Koordinate, oder? Dann frag' halt die Overpass-API nach allen Bildstöcken in einer gewissen BBox. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW Mautinformationen
Am 23.07.2012 17:24, schrieb Michael Herbold: Hallo, erst mal vielen vielen Dank für das zahlreiche und konstruktive Feedback. Wir haben heute früh schon angefangen, die Strecken entsprechend zu taggen (siehe http://www.openstreetmap.org/user/synyx/edits). Wie Robert S. korrekt bemerkt hat ist toll:hgv=yes nicht korrekt, da die Maut erst ab 12 Tonnen gilt. Den Vorschlag toll:N3=yes finden wir gut und würden dies auch an den bereits erstellen Tags anpassen (thx @ jimmy für den Vorschlag). Hier sollte man nur im Hinterkopf behalten dass die 12Tonnen Maut kein Naturgesetz ist. Ein Herabstufung auf 7,5Tonnen wurde auch schon diskutiert, eine parallele PKW-Maut mit abweichendem und/oder zeitabhängigem mautpflichtigem Strassennetzt wäre auch denkbar(Stichwort Verkehrslenkung). Die Problematik mit den impliziten Informationen ist uns bewusst. Prinzipiell haben wir kein Problem damit, dass mautpflichtige Autobahnen mit toll:N3=yes getaggt werden. Wie Jimmy schrieb, schliesst das eine das andere nicht aus. Wir haben bislang eben nur die mautfreien Teile getaggt. Ist es denn überhaupt gewollt, alle anderen Stelle mit yes zu taggen? Dies würde dazu führen, dass wirklich (fast) jedes Autobahnstück in Deutschland den Tag erhalten würde. Anderst wird es schwer zu unterscheiden ob ein Abschnitt nicht mautpflichtigt oder nur nicht getaggt ist. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW Mautinformationen
On 07/23/2012 06:17 PM, Garry wrote: Am 23.07.2012 17:24, schrieb Michael Herbold: Hallo, erst mal vielen vielen Dank für das zahlreiche und konstruktive Feedback. Wir haben heute früh schon angefangen, die Strecken entsprechend zu taggen (siehe http://www.openstreetmap.org/user/synyx/edits). Wie Robert S. korrekt bemerkt hat ist toll:hgv=yes nicht korrekt, da die Maut erst ab 12 Tonnen gilt. Den Vorschlag toll:N3=yes finden wir gut und würden dies auch an den bereits erstellen Tags anpassen (thx @ jimmy für den Vorschlag). hmm, ich würde dann aber noch den Geltungsbereich des 'N3' einbeziehen. Nicht dass die USA noch 'N3' = 'Bicycle' einführen für die man dann Toll zahlen muss. toll:EU:N3 oder wo auch immer diese 'N2' und 'N3' ihre Gültigkeit haben. Just my 2 [EUR]ct. Gruß, Toni ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW Mautinformationen
Am 23.07.2012 18:27, schrieb Toni Erdmann: On 07/23/2012 06:17 PM, Garry wrote: Am 23.07.2012 17:24, schrieb Michael Herbold: Hallo, erst mal vielen vielen Dank für das zahlreiche und konstruktive Feedback. Wir haben heute früh schon angefangen, die Strecken entsprechend zu taggen (siehe http://www.openstreetmap.org/user/synyx/edits). Wie Robert S. korrekt bemerkt hat ist toll:hgv=yes nicht korrekt, da die Maut erst ab 12 Tonnen gilt. Den Vorschlag toll:N3=yes finden wir gut und würden dies auch an den bereits erstellen Tags anpassen (thx @ jimmy für den Vorschlag). hmm, ich würde dann aber noch den Geltungsbereich des 'N3' einbeziehen. Nicht dass die USA noch 'N3' = 'Bicycle' einführen für die man dann Toll zahlen muss. toll:EU:N3 oder wo auch immer diese 'N2' und 'N3' ihre Gültigkeit haben. ...nur das damit keiner mehr etwas anfangen kann. Wenn ich mal ans extended access-Schema zurückdenke, wäre es sowas wie toll:hgv:(weight12)=yes Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Am 23.07.2012 17:41, schrieb Stefan Keller: Am 23. Juli 2012 13:16 schrieb aighes o...@aighes.de: Folgendes fehlt in deiner Zusammenfassung: Mit der OSM-IDs ist die Gefahr grösser als mit der UUID, dass das Projekt das Objekt verliert (da es einer gelöscht und mit denselben Tags neu erstellt hat). Wenn jemand das Objekt ändert, dann muss das Projekt so oder so überprüfen. Daher die UUID, bzw. die Projekt-ID Kannst du mal ein konkretes Beispielszenario nennen, wo das so ist? Aber es ist doch immer ein Objekt an nahezu einer Koordinate, oder? Dann frag' halt die Overpass-API nach allen Bildstöcken in einer gewissen BBox. Eine BBox taugt nicht als Identifikator. Wenn das Objekt verschoben wurde, dann ist es weg, ausserhalb der BBOX. Verstehe ich nicht. Wenn es in der BBox nicht mehr ist, wird es wohl nicht mehr das gleiche Objekt sein, dass man gemeint hat. In jedem Fall sollte dann das Projekt überprüfen, ob ihre Daten noch zu dem neuen Objekt passen. Bspw. Restaurantführer: Wenn die Anzahl der Tische etc. erfasst haben, wäre es fatal, die Daten nach einem Umzug nicht zu aktualisieren. Man will also wissen, ob das Objekt sich deutlich bewegt hat. Beim blinden kopieren der UUID merkt man davon leider nicht viel. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Warnungen beim Erzeugen einer Navit Karte (Österreich)
Danke für die Liste! Eine fehlende turn restriction hat ein Loch in der B92 nähe Klagenfurt aufgezeigt, da hätte es massive Routing Probleme gegeben. LG Jimmy PS: Zusätzlich habe ich gelernt, dass in der ein oder anderen Volksschule maximal 30km/h erlaubt sind :D ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW Mautinformationen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 23.07.2012 15:22, schrieb Jimmy_K: Kommt aus dem Englischen Raum. International eher unter LGV (Large Goods Vehicle) bekannt. Wird für Fahrzeuge genommen, welche unter die Kategorie N2 und N3 der EU fallen (somit Fahrzeuge zur Güterbeförderung über 3,5t bis 12t und über 12t). Danke für die Info! An dieser Stelle werden sich garantiert ein paar Leute (inkl. mir und ich denke da nur an Martin) dran stoßen. Das hieße, dass ein nicht existierendes Tag eine Information ist. Das ist meiner Meinung nach nicht so gewollt, da nicht gepflegte Tags nicht bedeuten, dass dahinter eine Information liegt. Diese Schlussfolgerung kann aber durch dein vorgeschlagenes Vorgehen sehr leicht entstehen. Es wäre nicht der erste Tag, welcher standardisiert auf yes gesetzt wird. (auf der Autobahn z.b. auch oneway), falls ich deine Kritik richtig verstanden habe. Ich fürchte, ich habe mich ungenau ausgedrückt. Wenn man nur die Autobahnen mit toll:hgv=no setzt, von denen man weiß, dass sie mautfrei sind, finde ich das ok. Problem ist aber (wie bei oneway=yes), dass der Umkehrschluss gefährlich ist. Nur weil ein Way kein toll:hgv=no (bzw. kein oneway=yes) hat, heißt es nicht, dass der Weg mautbelegt (bzw. keine Einbahnstraße) ist. Gruß, Philip -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlANixsACgkQYNYFUFLXAD1rPwCfSjUSR9+Ly+oY/ePVW6df1yQM 7lQAnRmylirniGBVfqibpuC2WbXnPSwp =sogR -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW Mautinformationen
On 07/23/2012 06:37 PM, aighes wrote: Am 23.07.2012 18:27, schrieb Toni Erdmann: On 07/23/2012 06:17 PM, Garry wrote: Am 23.07.2012 17:24, schrieb Michael Herbold: Hallo, erst mal vielen vielen Dank für das zahlreiche und konstruktive Feedback. Wir haben heute früh schon angefangen, die Strecken entsprechend zu taggen (siehe http://www.openstreetmap.org/user/synyx/edits). Wie Robert S. korrekt bemerkt hat ist toll:hgv=yes nicht korrekt, da die Maut erst ab 12 Tonnen gilt. Den Vorschlag toll:N3=yes finden wir gut und würden dies auch an den bereits erstellen Tags anpassen (thx @ jimmy für den Vorschlag). hmm, ich würde dann aber noch den Geltungsbereich des 'N3' einbeziehen. Nicht dass die USA noch 'N3' = 'Bicycle' einführen für die man dann Toll zahlen muss. toll:EU:N3 oder wo auch immer diese 'N2' und 'N3' ihre Gültigkeit haben. ...nur das damit keiner mehr etwas anfangen kann. Wenn ich mal ans extended access-Schema zurückdenke, wäre es sowas wie toll:hgv:(weight12)=yes ich weiß, kaum hatte ich die Mail mit toll:EU:N3 abgeschickt, fiel mir was anderes (besseres?) bzw. Gegenargumente ein. Toni ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Warnungen beim Erzeugen einer Navit Karte (Schweiz)
Am Sunday 22 July 2012 schrieb Tobias Knerr: Am 22.07.2012 21:34, schrieb aighes: Deutlich besser: Mach eine Liste draus, zerhacke sie in sinnvolle Paketgrößen und pack sie auf eine Wiki-Seite. Wie bei anderen ähnlichen Aktionen üblich. Würde ich auch besser finden. Ich halte solche Listen zwar grundsätzlich schon für hilfreich, aber habe jetzt natürlich keine Ahnung, ob schon jemand Einträge darauf abgearbeitet hat, und wenn ja welche. Sollte nächstes Mal besser wie eine der älteren Aktionen im Wiki aufgezogen werden: http://wiki.openstreetmap.org/wiki/Aktionen Und dann _eine_ Mail mit Link auf die entsprechende Wikiseite schicken. Die Wiki-Seite aufsetzen schaffe ich vermutlich nicht alleine, gibt es Freiwillige die den Teil übernehmen können und wollen? Danke und Gruß Rainer -- Rainer Dorsch http://bokomoko.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neuer OSMI-Layer fuer Lizenzwechsel-Resultate
Hallo, vorweg einmal: danke, super Arbeit! Am 2012-07-23 12:43, schrieb Hartmut Holzgraefe: von der logischen Abstufung rot-orange-gelb her ist das zwar völlig OK und nachvollziehbar, aber mit der Sichtbarkeit von gelb hab ich so meine Probleme, insb. wenn es über highway=tertiary liegt ... :( Wenn ich etwas monieren könnte, dann wäre es wohl auch die Farbwahl. Wenn da noch was geändert würde, würd ich mich sicher nicht beschweren ... ;) Frederik Ramm frede...@remote.org wrote: ..., aber es gab Leute, die meinten, man sollte das noch sehen koennen. Der Meinung bin ich auch. Am 2012-07-23 15:24, schrieb Sven Geggus: Ich meine wenn jemand einen solchen Weg in den Fingern hatte, dann ist der doch meist wieder OK oder? Jein, nicht zwangsläufig. Ich habe in Wien im 4., 5. und 6. Bezirk mittlerweile auch einiges an Straßen korregiert bzw neu angelegt, und das hauptsächlich basierend auf dem Wiener Stadtplan. Das heißt aber noch nicht unbedingt, dass ich dadurch auch alles erfassen konnte, was vorher eingetragen war. Für Leute, die zB aufgrund persönlichen Wissens Informationen haben, die über den Stadtplan hinausgehen ist es mMn sehrwohl wichtig zu wissen, dass dieser Way/Node vom Bot betroffen war und da potenziell nach Daten fehlen könnten. Lg Christan user:grimnirson ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neuer OSMI-Layer fuer Lizenzwechsel-Resultate
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo, von mir auch ein großes Dankeschön! Es erleichtert das Remapping doch ungemein, wenn man direkt auf einen Blick die Lücken erkennt. Am 23.07.2012 21:24, schrieb Christian Hauer: Hallo, vorweg einmal: danke, super Arbeit! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQDadRAAoJEOxzIRGma6mXZWUH/0dtd7VN/ZanEjgV1qJrE2QD 4GylfhrhQ6mpKzIlT3ZwHofba22lbouo/RGPT/P0hWPsF9jp1qI+NkcpfBSifCfD 2iDMJMb6eMulg2nZGRSUA3L99OexBdQEvhUXlMfPzqV0Rce0wY50Yz3v9S+SMLaH ruKfo9mHAUL8wsLhYYNic3lEAdYID2uc6cLw6xtQpfxYd2luKpVOXiN5AAKKpoh7 7XlOT2iE8Vc2zJECLW+78drpg1nI+jilD1NBdNJ27XzGK3VdEKzjw7qD9DIKueSQ QfDVnphJ/olsomcK8GVe5beUqDD3dxjwBiUGUxlBnSrdj4i9uS/wEuIc1B5eGv4= =tyAj -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW Mautinformationen
On 23/07/12 19:55, Toni Erdmann wrote: On 07/23/2012 06:37 PM, aighes wrote: Am 23.07.2012 18:27, schrieb Toni Erdmann: On 07/23/2012 06:17 PM, Garry wrote: Am 23.07.2012 17:24, schrieb Michael Herbold: Hallo, erst mal vielen vielen Dank für das zahlreiche und konstruktive Feedback. Wir haben heute früh schon angefangen, die Strecken entsprechend zu taggen (siehe http://www.openstreetmap.org/user/synyx/edits). Wie Robert S. korrekt bemerkt hat ist toll:hgv=yes nicht korrekt, da die Maut erst ab 12 Tonnen gilt. Den Vorschlag toll:N3=yes finden wir gut und würden dies auch an den bereits erstellen Tags anpassen (thx @ jimmy für den Vorschlag). Bitte verwendet besser verständliche Tags. Mit N2 bzw N3 kann man nicht viel anfangen und erschließen lassen sich solche Abkürzungen auch nicht. Auch kann man nicht so einfach einen neuen access tag einführen. hmm, ich würde dann aber noch den Geltungsbereich des 'N3' einbeziehen. Nicht dass die USA noch 'N3' = 'Bicycle' einführen für die man dann Toll zahlen muss. toll:EU:N3 oder wo auch immer diese 'N2' und 'N3' ihre Gültigkeit haben. ...nur das damit keiner mehr etwas anfangen kann. Sowas sollte man auf jedenfall vermeiden und lieber eine Bezeichnung Wenn ich mal ans extended access-Schema zurückdenke, wäre es sowas wie toll:hgv:(weight12)=yes Finde ich schon verständlicher. Wäre diese Diskussion nicht besser bei tagging@ aufgehoben ? Gruß fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neuer OSMI-Layer fuer Lizenzwechsel-Resultate
Hi Frederik, ich finde das prima, was du da gebastelt hast. Danke! Toll wäre es, wenn es auch ein Plugin für JOSM geben würde (so wie das Lizenzprüfungsplugin). O:-) Schönen Abend noch Harald Am 23.07.2012 12:23, schrieb Frederik Ramm: Hi, auf http://tools.geofabrik.de/osmi/?view=redactionbotlon=7.84268lat=48.78466zoom=5 gibt es einen neuen OSMI-Layer, der zeigt, was beim Lizenzwechsel-Bot passiert ist: ROT - Sachen, die der Bot geloescht hat. Der OSMI zeigt noch die alten Tags an, aber bitte nur angucken, nicht nach OSM hinein uebernehmen! ORANGE - Sachen, die der Bot geaendert hat. GELB - Sachen, die der Bot geanedert hat und die seitdem von jemand anders nochmal angefasst wurden. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neuer OSMI-Layer fuer Lizenzwechsel-Resultate
Am 23.07.2012 12:23, schrieb Frederik Ramm: gibt es einen neuen OSMI-Layer, der zeigt, was beim Lizenzwechsel-Bot passiert ist: Vorweg: ein rießen Dank an Frederik für das schnell Entwicken und Bereitstellen! [Als Anregung zum nachdenken] An alle welche verzweifelt nach einem Tool geschreihen haben: da wird noch während der Bot aktiv ist und die Entwickler noch arbeiten sofort rumgemeckert und alles in ist Sche geschrieben. Und wenn die Abstellmaßnahmen dann nach kürzester Zeit da sind wird von diesen Leuten nicht mal Danke an diejenigen gesagt, welche es mit viel Aufwand und trotz anderer Aufgaben bewerkstellen... :-( Grüße, Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW Mautinformationen
Hi, On 23.07.2012 17:24, Michael Herbold wrote: Ist es denn überhaupt gewollt, alle anderen Stelle mit yes zu taggen? Dies würde dazu führen, dass wirklich (fast) jedes Autobahnstück in Deutschland den Tag erhalten würde. Sicher gibt es andere Loesungen. Erst einmal weiss ich nicht, ob der von Euch eingeschlagene Weg wirklich gut ist. Ob irgendwas mautpflichtig ist oder nicht, ist ja nicht sowas wie ein Tempolimit, dass sich alle Naslang aendert. Daher scheint es mir keine so gute Idee zu sein, das Vorhandensein oder Nichtvorhandensein einer Mautpflicht an jeden einzelnen Way dranzupappen. In Eurer Auswertung werdet ihr *sowieso* Heuristiken brauchen, die entscheiden, was zu tun ist, wenn z.B. 100m Strecke unterwegs irgendwo als mautfrei getaggt sind. Wenn man aber diese Heuristik mal hat, kann man dann nicht evtl. and die Auf-/Abfahrten irgendwie einen Mautpunkt setzen oder sowas, und wenn die Route da vorbeifuehrt, geht der Zaehler los oder so? Oder vielleicht etwas mit den Relationen machen? Euer Ja/Nein-Gemisch finde ich nicht gut ueberlegt: Eine Autobahn kostet Maut, wenn sie in Deutschland ist und nicht explizit als mautfrei getaggt ist, oder wenn sie in einem anderen Land ist und explizit als mautpflichtig getaggt ist. Eine Bundesstrasse kostet immer dann Maut, wenn sie explizit als mautpflichtig getaggt ist. Eine niederrangige Strasse kostet nie Maut, wenn sie in Deutschland ist, egal wie sie getaggt ist... Da blickt doch keiner mehr durch. Wenn es Euch aber Ernst ist damit, OSM einen Nutzen zu stiften, dann muss Euer Konzept auch von jedem gut auswertbar sein und nicht nur von Eurer Spezialheuristik (ausser natuerlich die wird Open Source). Zugleich faende ich die Idee, *saemtliche* Autobahnen in Deutschland mit toll:hgv=yes zu versehen, auch etwas problematisch. Vielleicht wirklich an die Relationen gehen, da muss man weniger aendern. Wenn eine Autobahn durchgehend mautpflichtig ist, koennte ja ein Tag an der Relation reichen. Aber siehe kuerzlich gefuehrte Relationsdiskussion ;) 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] LKW Mautinformationen
Am 23.07.2012 22:11, schrieb fly: Bitte verwendet besser verständliche Tags. Mit N2 bzw N3 kann man nicht viel anfangen und erschließen lassen sich solche Abkürzungen auch nicht. Wenn es einen gleichbedeutenden verständlicheren Begriff gäbe, fände ich das auch besser. Aber hast du einen Vorschlag? Am 23.07.2012 18:27, schrieb Toni Erdmann: hmm, ich würde dann aber noch den Geltungsbereich des 'N3' einbeziehen. Nicht dass die USA noch 'N3' = 'Bicycle' einführen für die man dann Toll zahlen muss. Dieses Problem lösen wir notfalls, wenn es eintritt. Derzeit haben wir auch für andere Begriffe und Kürzel wie hgv keinen Geltungsbereich angegeben. Warum jetzt damit anfangen? Wenn ich mal ans extended access-Schema zurückdenke, wäre es sowas wie toll:hgv:(weight12)=yes Finde ich schon verständlicher. Es gab da kürzlich eine Diskussion und Wiki-Voting dazu. Resultat: Sonderzeichen und variable Bedingungen im Key sind bei vielen Mappern und Entwicklern nicht erwünscht. Es macht wirklich keinen Sinn, das jetzt schon wieder ins Spiel zu bringen, denn seit dem letzten Mal hat sich an den Argumenten nichts geändert. Gruß, Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Hallo Manuel, Beispiel: Ich habe für unseren Heimat- und Geschichtsverein eine Karte gebaut, auf der alle Bildstöcke, Wegkreuze, Kirchen und Sehenswürdigkeiten als kleine Pinnadeln gezeigt werden. Beim Anklicken der Pinnadel geht ein Popup mit kurzem Text und einem Foto auf. Wenn doch jede Sehenswürdigkeit genug Material für eine Webseite hat (Foto und/oder Text reicht), dann mache am besten diese als Webseiten zugänglich (z.B. mit Basisurl + UUID als URL aus der Datenbank) und trage die URL als url=... oder website=... ein. Dann sieht jeder Mapper sofort, dass die Objekte wichtig genug sind, eine Website zu haben und kann damit umgehen, da im Gegensatz zur UUID ja der Zweck des Tags ohne Recherche erkennbar ist. Als meistens gewünschter Nebeneffekt verbessert das auch die Auffindbarkeit für Suchmaschinen und macht gezielt Werbung für Euer Projekt. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neuer OSMI-Layer fuer Lizenzwechsel-Resultate
Hallo Frederik, besten Dank auch aus Italien. Ist genau das, was wir jetzt brauchen. Volker 2012/7/23 Frederik Ramm frede...@remote.org Hi, auf http://tools.geofabrik.de/**osmi/?view=redactionbotlon=7.** 84268lat=48.78466zoom=5http://tools.geofabrik.de/osmi/?view=redactionbotlon=7.84268lat=48.78466zoom=5 gibt es einen neuen OSMI-Layer, der zeigt, was beim Lizenzwechsel-Bot passiert ist: ROT - Sachen, die der Bot geloescht hat. Der OSMI zeigt noch die alten Tags an, aber bitte nur angucken, nicht nach OSM hinein uebernehmen! ORANGE - Sachen, die der Bot geaendert hat. GELB - Sachen, die der Bot geanedert hat und die seitdem von jemand anders nochmal angefasst wurden. 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-dehttp://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW Mautinformationen
Hi, Frederik Ramm schrieb: In Eurer Auswertung werdet ihr *sowieso* Heuristiken brauchen, die entscheiden, was zu tun ist, wenn z.B. 100m Strecke unterwegs irgendwo als mautfrei getaggt sind. warum braucht man Heuristiken wenn z.B. das Ziel ist zu erfahren wie viele KM meiner Route über mautpflichtige Straßen geht? Zugleich faende ich die Idee, *saemtliche* Autobahnen in Deutschland mit toll:hgv=yes zu versehen, auch etwas problematisch. dem stimme ich zu, ist irgendwie nicht glücklich. Vielleicht wirklich an die Relationen gehen, da muss man weniger aendern. Wenn eine Autobahn durchgehend mautpflichtig ist, koennte ja ein Tag an der Relation reichen. Mhm, meinst du damit ein Relation für alle (nicht-)mautpflichtigen Autobahnen zu erstellen, oder vorhandene Relationen der Autobahnen um ein Tag zu erweitern? Bei letzterer Variante werden dann aber Probleme auftreten wenn nur ein kleiner Teil der Autobahn mautpflichtig sind ... :-/ oder habe ich dich hier falsch verstanden? viele gruesse pascal ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Hallo Henning Am 23. Juli 2012 18:45 schrieb aighes o...@aighes.de: Am 23.07.2012 17:41, schrieb Stefan Keller: Folgendes fehlt in deiner Zusammenfassung: Mit der OSM-IDs ist die Gefahr grösser als mit der UUID, dass das Projekt das Objekt verliert (da es einer gelöscht und mit denselben Tags neu erstellt hat). Wenn jemand das Objekt ändert, dann muss das Projekt so oder so überprüfen. Daher die UUID, bzw. die Projekt-ID Kannst du mal ein konkretes Beispielszenario nennen, wo das so ist? Siehe oben den Link zur Bushaltestelle in meiner Antwort vom 23. Juli 2012 13:34 an Georg. Scheint übrigens in JOSM zurzeit auch für Eingeweihte eine Herausforderung zu sein, so einen Node zu verschieben und die ID beizubehalten. Siehe auch Frederiks Antwort vom vergangenen August dazu: http://permalink.gmane.org/gmane.comp.gis.openstreetmap/59050 Aber es ist doch immer ein Objekt an nahezu einer Koordinate, oder? Dann frag' halt die Overpass-API nach allen Bildstöcken in einer gewissen BBox. Eine BBox taugt nicht als Identifikator. Wenn das Objekt verschoben wurde, dann ist es weg, ausserhalb der BBOX. Verstehe ich nicht. Wenn es in der BBox nicht mehr ist, wird es wohl nicht mehr das gleiche Objekt sein, dass man gemeint hat. In jedem Fall sollte dann das Projekt überprüfen, ob ihre Daten noch zu dem neuen Objekt passen. Es gibt etliche Gebiete, die ab Orthofotos abdigitalisiert wurden und die um mehrere Meter (bis zu 30!) falsch sind, weil die Orthofotos falsch waren. Da steht man mit BBox sprichwörtlich im Schilf. LG, Stefan Am 23. Juli 2012 18:45 schrieb aighes o...@aighes.de: Am 23.07.2012 17:41, schrieb Stefan Keller: Am 23. Juli 2012 13:16 schrieb aighes o...@aighes.de: Folgendes fehlt in deiner Zusammenfassung: Mit der OSM-IDs ist die Gefahr grösser als mit der UUID, dass das Projekt das Objekt verliert (da es einer gelöscht und mit denselben Tags neu erstellt hat). Wenn jemand das Objekt ändert, dann muss das Projekt so oder so überprüfen. Daher die UUID, bzw. die Projekt-ID Kannst du mal ein konkretes Beispielszenario nennen, wo das so ist? Aber es ist doch immer ein Objekt an nahezu einer Koordinate, oder? Dann frag' halt die Overpass-API nach allen Bildstöcken in einer gewissen BBox. Eine BBox taugt nicht als Identifikator. Wenn das Objekt verschoben wurde, dann ist es weg, ausserhalb der BBOX. Verstehe ich nicht. Wenn es in der BBox nicht mehr ist, wird es wohl nicht mehr das gleiche Objekt sein, dass man gemeint hat. In jedem Fall sollte dann das Projekt überprüfen, ob ihre Daten noch zu dem neuen Objekt passen. Bspw. Restaurantführer: Wenn die Anzahl der Tische etc. erfasst haben, wäre es fatal, die Daten nach einem Umzug nicht zu aktualisieren. Man will also wissen, ob das Objekt sich deutlich bewegt hat. Beim blinden kopieren der UUID merkt man davon leider nicht viel. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW Mautinformationen
Hallo Frederik, meiner Meinung nach ist die Maut eine Eigenschaft der Straße und sollte daher auch an der Straße getaggt werden und nicht an einer Routenrelation. Für eine Auswertung wäre es auch deutlich einfacher, wenn die Wege (in irgendeiner Form) entsprechend getaggt sind. Bei anderen Eigenschaften eines Weges erfassen wir ja auch nicht Start- und Endpunkt der Eigenschaft, sondern geben dem Weg diese Eigenschaft. Ich sehe jetzt erstmal keinen Grund hiervon abzuweichen. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Hallo Roland Am 23. Juli 2012 22:47 schrieb Roland Olbricht roland.olbri...@gmx.de: Wenn doch jede Sehenswürdigkeit genug Material für eine Webseite hat (Foto und/oder Text reicht), dann mache am besten diese als Webseiten zugänglich (z.B. mit Basisurl + UUID als URL aus der Datenbank) und trage die URL als url=... oder website=... ein. Dann sieht jeder Mapper sofort, dass die Objekte wichtig genug sind, eine Website zu haben und kann damit umgehen, da im Gegensatz zur UUID ja der Zweck des Tags ohne Recherche erkennbar ist. Als meistens gewünschter Nebeneffekt verbessert das auch die Auffindbarkeit für Suchmaschinen und macht gezielt Werbung für Euer Projekt. Genau in die Richtung geht auch mein Vorschlag, denn die URL (url=... oder website=...) wird damit zu einem Identifikator im Sinne meiner Projekt-ID. Ich würde statt BasisURL+UUID aber nicht die UUID nehmen - die ist mir zu lang - sondern einen kürzeren Identifikator, den ich innerhalb meines Projekts eindeutig und permanent halte. Das Problem ist wieder, dass nur wenige Sitzbänke Sehenswürdigkeiten sind und auch nicht alle bebildert sind, so dass man eine URL oder sonst etwas identifizierendes dran hängen kann. Was es braucht, ist einen erkennbaren Identifikator, der für alle für das externe Projekt relevanten OSM Objekte gilt. Daher mein Vorschlag einer Projekt-ID (z.B. schlafbank_id=...). Das geht in Richtung Linked Data, daher spreche ich von jetzt an alternativ von Projekt-ID/Linked Data ID. Die Projekt-ID ist eindeutig, gleichartig, erkennbar, werbewirksam und (dank dem externen Projekt) permanent. Frederik sprach in [1], dass UUID database bloat seien; das kann ich nachvollziehen. Das gilt aber für Projekt-ID/Linked Data ID nur bedingt, denn ein solches Projekt (bzw. externe Datenbank) gibt OSM etwas zurück für den minimalen Ballast den OSM tragen muss. LG, Stefan [1] http://permalink.gmane.org/gmane.comp.gis.openstreetmap/59050 Am 23. Juli 2012 22:47 schrieb Roland Olbricht roland.olbri...@gmx.de: Hallo Manuel, Beispiel: Ich habe für unseren Heimat- und Geschichtsverein eine Karte gebaut, auf der alle Bildstöcke, Wegkreuze, Kirchen und Sehenswürdigkeiten als kleine Pinnadeln gezeigt werden. Beim Anklicken der Pinnadel geht ein Popup mit kurzem Text und einem Foto auf. Wenn doch jede Sehenswürdigkeit genug Material für eine Webseite hat (Foto und/oder Text reicht), dann mache am besten diese als Webseiten zugänglich (z.B. mit Basisurl + UUID als URL aus der Datenbank) und trage die URL als url=... oder website=... ein. Dann sieht jeder Mapper sofort, dass die Objekte wichtig genug sind, eine Website zu haben und kann damit umgehen, da im Gegensatz zur UUID ja der Zweck des Tags ohne Recherche erkennbar ist. Als meistens gewünschter Nebeneffekt verbessert das auch die Auffindbarkeit für Suchmaschinen und macht gezielt Werbung für Euer Projekt. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Editordiskusion (war: Re: Off. Re: Zurueck in die Steinzeit)
Am 21.07.2012 12:19, schrieb buedner: Deinen Stolz, dass es Dir gelungen ist, Dich in den coolen Profieditor JOSM einzuarbeiten, kann ich durchaus verstehen. Da ist nichts mit Stolz! Und zum 1000sten mal: JOSM ist nicht kompliziert! Im Gegenteil: ich finde Potlatch so kompliziert und Bedienungs-Fehleranfällig, dass ich selbst für Kleinigkeiten JOSM nutze. Potlatch ist alles andere als selbsterklärend, ich komme damit nicht wirklich gut klar. Ich möchte aber zu bedenken geben, dass für jemanden, der nur OSM-Daten bearbeiten möchte, Potlatch ein hervorragendes Werkzeug ist. Ich nutze JOSM auch nur um OSM-Daten zu bearbeiten. Wozu soll ich JOSM sonst benutzen? Wir reden nicht über QGIS oder sonstigen klassische GIS-Software sondern über JOSM, den Java-OSM-Editor. Der allergrößte Teil der Editierarbeiten ist damit ohne große Einarbeitungszeit effizient zu erledigen, übrigens auch für den Profi. Auch mit JOSM lassen sich ohne großen Aufwand und ohne große Einarbeitung sehr effizient Editierarbeiten zu erledigen, für den Profi aber auch sehr wohl für den Anfänger. M.E. sogar effizienter als in Potlatch. Ich empfinde daher die leichte Überheblichkeit, die hier gelegentlich gegenüber Potlatch-Nutzern zum Ausdruck kommt, als etwas peinlich. Da ist nichts mit Überheblichkeit. Meine Abneigung gegenüber Potlatch hat andere Gründe: diese Liegen in seiner Vergangenheit und seinen grundsätzlichen Schwächen. * früher war jeder Edit live. Immerhin hat man jetzt die Möglichkeit (aber AFAIK leider nicht den Zwang! [1]) die Änderungen erst am Ende zu speichern. Bei JOSM muss ich am Ende immer bewusst hochladen, das ist immer die Chance für einen Notaus (= verwerfen der Änderungen wenn ich mir nicht sicher bin ob ich gröbere Fehler gemacht habe). * in JOSM kann ich beliebig rumspielen, da passiert nichts. Ich denke dass vielen Anfängern gar nicht bewusst war, dass sie mit dem vereintlichen Anfängertool Potlatch in einer Live-Datenbank agieren und somit beim Ausprobieren sofort Schaden anrichten... * Potlatch hat bis vor kurzem nicht alle Daten angezeigt, welche in der Datenbank sind (ich weiss jetzt nicht mehr was er in der Anzeige unterschlagen hat). Ich weiss auch nicht ob das zwischenzeitlich gefixt ist. So etwas geht für mich gar nicht. * Einige Potlatch-Versionen habe IIRC mehr oder weniger alle Objekte im Fenster angefasst, auch wenn sie nicht verändert worden sind. Auch dadurch sind in der Lizenzumstellung Problem entstanden! * Potlatch kann nur die Daten bearbeiten, welche auf dem Server sind. Wenn ich meine GPS-Tracks aber aus [welchen Gründen auch immer] nicht hochladen will, kann ich sie in Potlatch nicht verwenden * Kann ich für Fotomapping Fotos in großer Zahl verwenden welche bei mir auf der Platte liegen und am Aufnahmeort im Editor angezeigt werden? Ich befürchte nicht. * Die Performance von Potlatch war in der Vergangenheit nervig (bis immer der Hintergrund neu gezeichnet wurde), vielleicht ist das zwischenzeitlich besser. UNd bei einer dünnen Internetverbindung ist das noch grausamer. * Welche Hintergründe kann ich außer Bing haben? Ich habe teilweise sehr unterschiedliche und mehr oder weniger exotische Wünsche für Hintergründe (z.B. für Spanien oder Bayern2m) * ... [ich könnte weitere für mich gültige Gründe aufzählen] Sicher ist auch JOSM nicht perfekt. Aber m.E. ist JOSM im direkten Vergleich das wesentlich kleinere Übel. Grüße, Michael. zu [1]: man korrigiere mich bitte, wenn das zwischenzeitlich geändert wurde ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Hallo Frederik Am 24. Juli 2012 00:03 habe ich in meiner Antwort an Roland nochmals darauf hingewiesen, dass ich einen erkennbaren Identifikator meine, der für alle für das externe Projekt relevanten OSM Objekte gilt und auch für solche funktioniert, die keine besonderen Merkmale haben. Daher mein Vorschlag einer Projekt-ID (z.B. schlafbank_id=...), was in Richtung Linked Data geht. Diese Projekt-ID/LinkedData-ID ist eindeutig, gleichartig, erkennbar, werbewirksam und (dank dem externen Projekt) permanent. In diesem Sinne gibt die externe Datenbank (die ähnlich deinem Vorschlag gemeint ist) etwas zurück für den minimalen Bloat den OSM wegen der Projekt-ID/LinkedData-ID tragen muss. Was ich bei deinem Vorschlag einer externen Datenbank noch etwas konkretisieren möchte ist folgendes: * Wie geht man hier mit OSM Objekten um, auf die kein fuzzy link definiert werden kann (wie z.B. Sitzbänke)? * Du sprichst davon, dass jedermann stored queries auf fuzzy links (im Sinne Tim Alders query-to-map) anlegen kann: An welche Query-Syntax hast du gedacht? * Wieso sollten solche queries/fuzzy links nicht gerade von den Betreibern der externen Datenbank in OSM eingetragen werden? * Bisher haben wir von externen Datenbanken gesprochen - also Mehrzahl: Gehört so eine externe Datenbank nicht eigentlich zur OSM Infrastruktur? LG, Stefan Am 22. Juli 2012 22:58 schrieb Frederik Ramm frede...@remote.org: Hallo, ich bin der Ansicht, das OSM-IDs eine 100% OSM-interne Sache sind, auf die sich niemand sonst verlassen darf, weil dies die Handlungsmoeglichkeiten bei OSM einschraenkt. Im rein hypothetischen Fall, dass OSM irgendwann einmal beschliessen sollte, seine Daten auf mehrere Server auf verschiedenen Kontinenten aufzuteilen und daher alle Objekte auf neue Server mit neuen Nummernraeumen verteilt, sollte das niemanden stoeren. Im rein hypothetischen Fall, dass OSM irgendwann alle existierenden Objekte umnumeriert, um nicht mehr genutzte Luecken wiederzuverwenden, sollte das keine Probleme verursachen. Im rein hypothetischen Fall, dass jemand einen Ort komplett loescht und neu einfuegt, sollte niemand davon etwas merken. Darauf hinzuarbeiten, dass OSM-IDs moeglichst stabil sein sollen, wuerde zugleich heissen, die Flexibilitaet der Mapper zu reduzieren, ihnen das Leben schwerer zu machen - m.E. keine gute Idee. UUIDs stehe ich ebenfalls sehr kritisch gegenueber, weil sie das Fuehren der Link-Stabilitaet unseren Mappern aufbuerden. Ich finde, unser Mapper soll sich damit beschaeftigen, dass da ein Restaurant mit dem Namen X ist, und wenn das Restaurant umzieht auf die andere Strassenseite, dann loescht er das und legt es neu an, oder er schiebt es rueber, ganz wie es gerade am geeignetsten erscheint. Die UUID-Diskussion wurde schon oft gefuehrt, und es konnte meines Erachtens nie schluessig dargelegt werden, was die UUID genau sein soll. Eine UUID fuer die ganze Bachstrasse, oder eine fuer jeden Teil-Way? Wenn ich ein denkmalgeschuetztes Haus mappe und drin ist ein Restaurant, und ich gebe dem Way eine UUID, und spaeter zieht das Restaurant um auf die andere Strassenseite - woher weiss ich dann, ob ich die UUID mit umziehen muss (weil sie in einem Restaurantfuehrer verwendet wird) oder nicht (weil sie in einem Architekturfuehrer verwendet wird)? Aha, wir brauchen mehrere UUIDs pro Objekt, eine fuer jeden Aspekt... Laut Overpass's Permanent ID könnte die Lösung eine eindeutige Eigenschaft des Objekts sein, typischerweise eine Kombination von Tags. Als Beispiel wird eine Relation mit den Tags network=BAB und ref=A 516 herangezogen. Ich finde den Vorschlag gut - man muss sich aber bewusst sein, dass er m.E. nichts Neues bringt, bzw. das Problem der offenbar unvermeidbaren menschlich- und technischen Unzulänglichkeiten nicht löst. Ich halte das fuer die beste Loesung, die wir haben, weil hier derjenige, der den Link setzt, entscheiden muss, was ihm wichtig ist, und die Mapper sich nicht damit herumschlagen muessen. Das Problem der unvermeidbaren Unzulaenglichkeiten wird dadurch nicht geloest, aber reduziert - wenn ich ein Restaurant loesche und auf der anderen Strassenseite neu zeichne, wird das immer noch gefunden. Eine OSM-externe Datenbank vergibt einen eigenen und für sie eindeutigen ID-Tag in OSM, die nicht-sprechende Identifikatorwerte erhalten, z.B. unserprojekt:id=10001 oder unserprojekt_id=10001. Nein, das halte ich nicht fuer akzeptabel, es hat die gleichen Probleme wie das UUID-Konzept. Was aber eine gute Idee waere: Man baut eine externe Datenbank als Interface zwischen der Oeffentlichkeit und OSM auf. Zur Oeffentlichkeit hin unterstuetzt diese Datenbank permanente Schluessel - seien das UUIDs oder Nummern oder sonstwas. Zu OSM hin benutzt diese Datenbank das Overpass-Permanent-ID-Konzept (das nicht von Roland erfunden wurde, sondern ursrpuenglich mal von Tim Alder mit seinem query to map angedacht worden war). Jeder kann bei Bedarf einen
Re: [Talk-de] LKW Mautinformationen
Am Dienstag, den 24.07.2012, 00:00 +0200 schrieb aighes: Hallo Frederik, meiner Meinung nach ist die Maut eine Eigenschaft der Straße und sollte daher auch an der Straße getaggt werden und nicht an einer Routenrelation. Für eine Auswertung wäre es auch deutlich einfacher, wenn die Wege (in irgendeiner Form) entsprechend getaggt sind. Bei anderen Eigenschaften eines Weges erfassen wir ja auch nicht Start- und Endpunkt der Eigenschaft, sondern geben dem Weg diese Eigenschaft. Ich sehe jetzt erstmal keinen Grund hiervon abzuweichen. Henning +1 Jörg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Hallo, Am Sonntag, den 22.07.2012, 21:22 +0200 schrieb Stefan Keller: 1. Sind OSM ID's wirklich instabil? bzw. Wann ändern IDs ungewollt/unfreiwillig? Oben wird die Overpass Permanent ID erwähnt (http://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID ) und dort steht: ...you shouldn't use an object ID, because the OSM IDs may change at any time. Das würde ich gerne mal näher analysieren: Ein klarer Fall für ein Löschen und Neu-Einfügen (mit neuer ID) scheint mir zu sein, wenn das auch in der realen Welt der Fall ist: Wenn z.B. ein Gebäude abgerissen und neu erstellt wird, oder ein wichtiger Einzelbaum gefällt und neu gepflanzt wird. Soeben realisiere ich, dass wenn Nodes (mit Tags) lagemässig verschoben werden, ein neuer Node mit neuer ID und neuen Koordinaten und den geretteten Tags erzeugt wird (zumindest in JOSM), während dessen alte Koordinaten als normaler Way-Node zurückbleiben. Das ist aber kein logisch zwingender Grund, sondern technischer Mangel. Dieses Problem lässt sich umgehen, wenn man nicht mit der Version des Weges arbeitet, sondern zusätzlich mit einem Datum. Ein way X lässt sich zu jedem Zeitpunkt und immer gleich aus OSM (und der OSM-Historie) extrahieren. Dieses Objekt(mit Datum) ist stabil. Diese Information ließen sich cachen und bei Bedarf gegen die Objekte mit aktuellerem Datum abgleichen. Wie kommt man an das Objekt mit ObjektID+Datum? -- alle referenzierten Objekte mit dem entsprechenden Datum ermitteln. Die Ermittlung ist ohne komplette Datenbank mit OSM-Historie sehr aufwändig. Vor einigen Jahren habe ich mal einen Prototypen geschrieben, der über die API aus der OSM-DB ein Objekt zu jedem Zeitpunkt ermitteln kann: Beschreibung: http://www.h-renrew.de/h/osm/tools/osmhistory.html Quelltext: https://github.com/werner2101/python-osm Anmerkungen: * Bei der Eindeutigkeit gibt es eine gewisse Unschärfe, weil die Changesets AFAIK nicht atomar in die OSM-Datenbank eingetragen werden. * Ich weiß nicht ob der Code mit Objekten noch geht, die vom Redaction Bot verändert wurden. Grüße Werner ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [osm-ve] Maracay Mapa Borrado
Hola a todos, Noté tambien que hubo vandalismo en la version francesa de OSM, alguien que no estuvo de acuerdo con el cambio de licencia ODbL (un tipo un poco raro : http://lists.openstreetmap.org/pipermail/talk/2012-July/063543.html), cierto que no estoy al tanto de todos los detalles de la licencia como muchos de uds, pero quiza no tendra algo que ver con eso ? quiza me equivoco totalmente. Solo les aviso por si acaso. Carmen. 2012/7/23 J. Rojas rojas...@gmail.com: Afortunadamente si hay buenas imagenes de bing en Maracay. Otra ciudad que recuperar. El 22 de julio de 2012 19:14, hyan...@gmail.com hyan...@gmail.com escribió: Maracay tiene cobertura Bing. El día 22 de julio de 2012 18:40, hyan...@gmail.com hyan...@gmail.com escribió: Enlace permanente (permanent link) de Maracay http://www.openstreetmap.org/?lat=10.2435lon=-67.6004zoom=12layers=M Para obtenerlo hay que dar click al enlace en la parte inferior-derecha del mapa. El día 22 de julio de 2012 17:54, J. Hernán Ramírez R. hernan.rami...@gmail.com escribió: Haz un zoom de la zona y envía el link para revisar -- Salva un árbol. No imprimas este correo a menos que sea realmente necesario. - J. Hernán Ramírez R Blog - Linux User #97.898 - Twitter @HernanRamriez Mapas Libres OpenStreetmap Venezuela - 2012/7/22 J. Rojas rojas...@gmail.com Ok fijandome en otra zona tenemos el mismo inconveniente que con La Victoria, en este caso les dejo el Link Maracay para que observen que tambien cierta data ha sido eliminada. creo que hemos perdido informacion en otra zona hay que seguir chequeando. -- J. Rojas ___ Talk-ve mailing list Talk-ve@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ve ___ Talk-ve mailing list Talk-ve@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ve ___ Talk-ve mailing list Talk-ve@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ve -- J. Rojas ___ Talk-ve mailing list Talk-ve@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ve ___ Talk-ve mailing list Talk-ve@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ve
Re: [osm-ve] Maracay Mapa Borrado
El tema del cambio de licencia tuvo un periodo de discusión de casi tres años, básicamente obedece a que Creative Commons no está diseñada para proteger propiedad intelectual en forma de datos, eso es todo. Entonces en el contexto legal de OSM hay dos licencias, CC-BY-SA que protege las imágenes renderizadas producto de los datos (mapnik) y OdBL que protege los datos contenidos dentro de la base de datos. Para más información sobre la licencia por favor referirse a: http://opendatacommons.org/licenses/odbl/ El día 23 de julio de 2012 03:00, Carmen Brando carmen.bra...@gmail.com escribió: Hola a todos, Noté tambien que hubo vandalismo en la version francesa de OSM, alguien que no estuvo de acuerdo con el cambio de licencia ODbL (un tipo un poco raro : http://lists.openstreetmap.org/pipermail/talk/2012-July/063543.html), cierto que no estoy al tanto de todos los detalles de la licencia como muchos de uds, pero quiza no tendra algo que ver con eso ? quiza me equivoco totalmente. Solo les aviso por si acaso. Carmen. 2012/7/23 J. Rojas rojas...@gmail.com: Afortunadamente si hay buenas imagenes de bing en Maracay. Otra ciudad que recuperar. El 22 de julio de 2012 19:14, hyan...@gmail.com hyan...@gmail.com escribió: Maracay tiene cobertura Bing. El día 22 de julio de 2012 18:40, hyan...@gmail.com hyan...@gmail.com escribió: Enlace permanente (permanent link) de Maracay http://www.openstreetmap.org/?lat=10.2435lon=-67.6004zoom=12layers=M Para obtenerlo hay que dar click al enlace en la parte inferior-derecha del mapa. El día 22 de julio de 2012 17:54, J. Hernán Ramírez R. hernan.rami...@gmail.com escribió: Haz un zoom de la zona y envía el link para revisar -- Salva un árbol. No imprimas este correo a menos que sea realmente necesario. - J. Hernán Ramírez R Blog - Linux User #97.898 - Twitter @HernanRamriez Mapas Libres OpenStreetmap Venezuela - 2012/7/22 J. Rojas rojas...@gmail.com Ok fijandome en otra zona tenemos el mismo inconveniente que con La Victoria, en este caso les dejo el Link Maracay para que observen que tambien cierta data ha sido eliminada. creo que hemos perdido informacion en otra zona hay que seguir chequeando. -- J. Rojas ___ Talk-ve mailing list Talk-ve@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ve ___ Talk-ve mailing list Talk-ve@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ve ___ Talk-ve mailing list Talk-ve@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ve -- J. Rojas ___ Talk-ve mailing list Talk-ve@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ve ___ Talk-ve mailing list Talk-ve@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ve ___ Talk-ve mailing list Talk-ve@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ve
[Talk-in] osm workshop in Trivandrum - help needed
hi, I had addressed a couple of mails on this subject. I think it is time to be more elaborate, and we need help from this group to take things further. Icfoss is an autonomous institution set up by the government of Kerala to promote open source (http://icfoss.in/). I happened to meet the director at a conference and was surprised to find that he knew what he was talking about. He was raving about all the good work a friend of his was doing for google maps. I introduced him to osm, and he was enthusiastic about the concept and felt a workshop should be conducted in tvm to build up the community and to get the government interested. After some discussion he has offered to fund the venue, lunch and snacks and infrastructure for a one day workshop and he has duly booked a venue for the 18th. However he has 2 constraints: 1 he wanted the sanction of the OSM community to conduct the workshop - since we do not have a formal community here, I contacted Mikel who was good enough to send a formal letter of support in his capacity as a member of the OSMF council which solved that problems. 2. he needs one or more local volunteers to liase with icfoss and do the ground work like making sure the venue is ready, registering the delegates etc. Here I am stuck as all the people I knew in Kerala are now in Bangalore. The volunteers need not be OSM people - people interested in learning about it are enough. There are some more points I need to make, but I want this mail to go out today - I will follow up tomorrow. Opportunities like this do not come up very often - it would be good for the community if we can make best use of it. -- regards Kenneth Gonsalves ___ Talk-in mailing list Talk-in@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-in
Re: [Talk-in] Data loss due to license change
On Sun, Jul 22, 2012 at 11:09 AM, Sajjad Anwar sajja...@gmail.com wrote: I'll start cleaning up bits of Kerala first and then give you a hand in Bangalore. I've done some immediate patchwork in South Bangalore. This is the area that seems to be most affected - http://osm.org/go/yy4ZVaP8- Don't navigate on those roads via OSM ;-) Cheers, Sajjad. ___ Talk-in mailing list Talk-in@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-in
Re: [Talk-it] Google si mette in proprio anche in Italia
Il 23 luglio 2012 06:10, EdoardoT tona.edoa...@gmail.com ha scritto: Questa è troppo forte... Guardate in mare a Livorno... Altro che ponte sullo stretto! Si va in corsica in macchina! Ahahah io ho appena scoperto che, al posto della casa dei miei, c'è il Grand Hotel Principi di Piemonte, che ovviamente non è un villino, e oltretutto sta proprio in un'altra città (Torino, invece del paese della cintura in cui vivono in miei) Pensa a quelli dell'hotel che magari pagano per essere evidenziati. -- Maurizio Daniele - maurizio.daniele (a) gmail.com ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] distanze città italiane
2012/7/23 Carlo Stemberger carlo.stember...@gmail.com Qualche giorno fa ho scambiato qualche chiacchiera con lo sviluppatore di ORSM, e gli ho reso noto un problema analogo: non si riesce ad accedere al centro di Viterbo. http://map.project-osrm.org/?**hl=itloc=42.417770,12.110190** loc=42.413699,12.097878loc=**42.416420,12.097330z=16** center=42.415164,12.099552df=**0http://map.project-osrm.org/?hl=itloc=42.417770,12.110190loc=42.413699,12.097878loc=42.416420,12.097330z=16center=42.415164,12.099552df=0 (probabilmente barrier=sally_port viene ignorato) C'è anche un problema a Vercelli. Non c'è modo di entrare in autostrada a Vercelli Est. Non capisco però se è un problema di mapping o dell'algoritmo di routing. Ciao, Andrea. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
