Re: [Talk-si] Talk-si izvleček, let 38, številka 2
Zdravo, Jaz v bistvu nisem ravno ekspert glede teh sprememb, pač opazujem iz višine. Je pa tudi v Brežicah in okolici, ker občasno mapiram, zginilo kar nekaj zadev (tudi celotno letališče Cerklje). Pri nekaterih cestah so pobrisani samo določeni nodi, verjetno ker lastnik ni šel v novo licenco. Bo pač treba ponovno vrisati, tokrat bo verjetno lažje, ker je dosti več GPS traceov. lp Igor 2012/7/22 Bostjan Golez bostjan.go...@gmail.com Zdravo, dajte mi tole malce razložit. Sem opazil da so določene ceste izginile, kako jih najenostavneje spravit nazaj? Pa niso zginle tiste, katere sem risal sam... Hvala in lp, BostiG Dne 21. julij 2012 13:00 je talk-si-requ...@openstreetmap.orgnapisal/-a: Sporočila za poštni seznam od osebe Talk-si pošljite na talk-si@openstreetmap.org Za prijavo ali odjavo s seznama prek interneta obiščite http://lists.openstreetmap.org/listinfo/talk-si prek e-pošte pa pošljite sporočilo z zadevo ali besedilom 'help' na talk-si-requ...@openstreetmap.org Skrbnika poštnega seznama najdete na naslovu talk-si-ow...@openstreetmap.org Pri odgovarjanju oblikujete vrstico z Zadevo, tako da bo bolj opisna od Re: Vsebina izvlečka za Talk-si... Današnje teme: 1. OSM izgube v Sloveniji (Igor Brejc) 2. Re: OSM izgube v Sloveniji (Blaž Lorger) -- Message: 1 Date: Fri, 20 Jul 2012 23:47:24 +0200 From: Igor Brejc igor.br...@gmail.com To: OSM-Talk-Si talk-si@openstreetmap.org Subject: [Talk-si] OSM izgube v Sloveniji Message-ID: CA+CKBJGO2ix64TbPLAA1O= wqridwpceyxvbz9znuvd-eobb...@mail.gmail.com Content-Type: text/plain; charset=utf-8 Zdravo, Tukaj lahko vidite rezultate čiščenja OSM baze zaradi spremembe licence: http://tools.geofabrik.de/osmi/debug.html?view=botlon=14.82520lat=46.18246zoom=9overlays=overview,bot_point_modified,bot_line_modified_cp,bot_line_modified,bot_point_deleted,bot_line_deleted_cp,bot_line_deleted (zoom in za bolj podroben vpogled) -- naslednji del -- HTML priponka je prečiščena... URL: http://lists.openstreetmap.org/pipermail/talk-si/attachments/20120720/25773456/attachment-0001.html -- Message: 2 Date: Sat, 21 Jul 2012 08:50:42 +0200 From: Blaž Lorger blaz.lor...@krs.net To: talk-si@openstreetmap.org Subject: Re: [Talk-si] OSM izgube v Sloveniji Message-ID: 201207210850.42841.blaz.lor...@krs.net Content-Type: Text/Plain; charset=utf-8 On Friday 20 July 2012 23:47:24 Igor Brejc wrote: Zdravo, Tukaj lahko vidite rezultate čiščenja OSM baze zaradi spremembe licence: http://tools.geofabrik.de/osmi/debug.html?view=botlon=14.82520lat=46.1824 6zoom=9overlays=overview,bot_point_modified,bot_line_modified_cp,bot_line _modified,bot_point_deleted,bot_line_deleted_cp,bot_line_deleted Hm, izgleda da ta prikaz ni ravno 100%. Mislim da objekti, ki sem jih popravil takoj po prehodu redaction bota, niso označeni. Izjema so tisti objekti, ki sem jih moral ponovno kreirati. Stari so označeni kot pobrisani. Predvidevam da so dan ali dva po prehodu bota pogledali katere objekte je nazadnje modificiral bot, niso pa gledali zgodovine objektov. Če je kdo v vmesnem času slučajno modificiral objekt, brez da bi popravil škodo, ki jo je naredil bot, so botove spremembe skrite. -- ___ Talk-si mailing list Talk-si@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-si Konec Talk-si izvleček, let 38, številka 2 ** -- --- Laze pri Dramljah 23 3222 Dramlje Slovenia GPS:http://maps.google.com/maps?f=qsource=s_qhl=engeocode=q=46.2669N+15.3864Esll=46.267033,15.386578sspn=0.001817,0.004823ie=UTF8ll=46.26707,15.386503spn=0.001817,0.004823t=hz=1846.2669N 15.3864E Mobile:+38631349505 Skype: bostjan_golez http://golez.wordpress.com http://www.pddramlje.si ___ Talk-si mailing list Talk-si@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-si ___ Talk-si mailing list Talk-si@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-si
Re: [OSM-legal-talk] Some questions about using ODbL Produced Work maps in Wikipedia
On Sun, Jul 22, 2012 at 3:04 AM, Frederik Ramm frede...@remote.org wrote: If it were any different, you could team up with a co-publisher, publish your ODbL Produced Works to him and he forwards them to the world without you ever having to release anything. It would be a loophole that demands quick fixing ;) Is this a valid (i.e., legal) interpretation of the word publish? My interpretation is that you make a work available to the general public for it to be considered as publishing (hence the etymology of publish which means to make public). So, conveying your work to a another entity and not the general public does not count as publishing. ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Some questions about using ODbL Produced Work maps in Wikipedia
Hi, On 22.07.2012 00:22, Paul Norman wrote: If CC4 comes out with such indiscrimante inclusion of database rights then my guess is that it will either be automatically impossible to licene Produced Works under CC, or we will have to explicitly disallow it. I'm not sure who you mean by we in that statement. If ODbL allowed produced works under CC4 the only people who could disallow it would be ODC with a license upgrade. OSMF couldn't stop produced works under CC4 licenses. The release of Produced Works under a CC license including database rights, and with that the danger of a complete and systematic reverse engineering under a CC license, would undermine one of the pillars of ODbL - the requirement to share a database from which Produced Works are made. I would estimate that ODC have something against that, and would react in some way. I don't know if the issue would be a big problem for us. It's possible that we just say: Oh well, if you think you need our data under CC4 then here you go. - we could even choose to dual-license at the source. That would weaken our share-alike quite a bit as everyone would use the license that requires them to share the least. A routing web site that operates on a clever enhanced routing tree would choose CC-BY-SA so they only have to release individual results and not the whole database; a publisher would choose ODbL so that they only have to release the database but not allow copying of the map. If we wanted to stop it, then the following actions could be possible: * lean on ODC to release new anti-Produced-Works-with-database-rights license; * execute CT license change procedure to change to homemade ODbL-with-extras license; * define that anything allowing the automated re-extraction of our data with less than x% precision loss is a derivative database and never a produced work -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Some questions about using ODbL Produced Work maps in Wikipedia
Hi, On 22.07.2012 08:43, Eugene Alvin Villar wrote: So, conveying your work to a another entity and not the general public does not count as publishing. I think that as far as viral licenses are concerned, the public is anyone who is not yourself, or part of your own organisation. I think that the CC licenses often use distribute or publicly perform... which makes this a bit clearer, but ODbL also contains the definition: “Publicly” – means to Persons other than You or under Your control by either more than 50% ownership or by the power to direct their activities (such as contracting with an independent consultant). Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] Very not happy
Am 22.07.2012 00:42, schrieb andrzej zaborowski: On 21 July 2012 15:07, Frederik Ramm frede...@remote.org wrote: That's quite incorrect, millions of objects that were not flagged in those tools have been removed, Can both of you give us the object IDs of a couple of these objects to investigate? If you're asking me (not Maetma 91), I think the problem has been known since the early days of OSMI license view (easily fixable too). For example this city I believe was showing as clean although it was a while since I have looked at that layer: http://osm.org/go/0MtRfiBy- Here's a before/after the bot run comparison someone made for that city: http://postimage.org/image/sv7gh0rkp/ http://postimage.org/image/8m60yvx8j/ First of all that's not the ID(s) Frederik asked for. Secondly: if it has been known to you - did you provide a patch or at least a patch idea for it? If it has been known before that there has been an error, then you cannot complain about it suddenly being deleted against the OSMI view - because obviously you knew about that already. You don't have to be a coder: if you know something is wrong and you can point the responsible developer to it, most devs are happy about that. Of course that not necessarily would have lead anyone to fix it in seconds, probably even not to fix it before the bot ran, but being silent and waiting for the obvious to complain afterwards definitively isn't the nice way of doing. regards Peter ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] City routing grid for Australia and the US
I already shared this on talk-us but since I have some degree of
worldwide coverage I guess I'll share it here too.
I noticed that the bot sometimes removed the highway=* tag but left
the oneway=* tag in place. At least here in the US, most such ways are
a part of the interstate system and since they are missing the highway
tag, greatly impact routing.
So I queried for ways with a oneway tag but no highway tag and put
them on a map. I am pre-rendering the tiles using Maperitive so
worldwide coverage only goes down to z10. I have added up to z13 in
some areas and will add more for higher density areas. I have already
done the UK, Spain/Portugal, some of France and the big cities in
Australia down to z13. You can see the map here:
http://ni.kwsn.net/~toby/OSM/maps/redaction.html
Or use it as a tile URL in JOSM:
tms:http://ni.kwsn.net/~toby/OSM/maps/oneway/{zoom}/{x}/{y}.png
I hope this will help to get some of the major routing problems fixed
up since these problems are a simple fix: just add the appropriate
highway=* tag.
Toby
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] City routing grid for Australia and the US
Kai, as I mentioned in talk-us (but I think you might have missed it), here's a few more cities for the US one that I would suggest adding that might help out in spotting problems. Pittsburgh Cleveland Las Vegas Toronto, Ontario, Canada (mainly because you added Winnipeg which is also in Canada)Montreal, Quebec, Canada -James___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] City routing grid for Australia and the US
Kai, as I mentioned in talk-us (but I think you might have missed it), here's a few more cities for the US one that I would suggest adding that might help out in spotting problems. Pittsburgh Cleveland Las Vegas Toronto, Ontario, Canada (mainly because you added Winnipeg which is also in Canada) Montreal, Quebec, Canada -James == On second thought, Nashville, TN would be a much better choice than Cleveland, OH. But I still also suggest the other cities I mentioned. Also add Miami, FL to that list. -James___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] City routing grid for Australia and the US
On Sat, Jul 21, 2012 at 11:21 PM, Kai Krueger kakrue...@gmail.com wrote: On Sat, Jul 21, 2012 at 8:56 PM, Svavar Kjarrval sva...@kjarrval.is wrote: I want to make a similar routing table file for my country. Any chance of giving us instructions on how to generate such routing grids of our own? - Svavar Kjarrval I have now pushed the code I used to generate those tables to github. ( https://github.com/apmon/RoutingGrid ) It is a little java program that takes in a list of coordinates and city names and generates the html file for the routing grid. You can easily run it on your own list of coordinates / cities. Thanks! I've just made a test one for Italy: http://maps.cortesi.com/distanze_italia.html -- -S ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] City routing grid for Australia and the US
On 22/07/12 03:49, Kai Krueger wrote: On 07/21/2012 04:56 PM, Svavar Kjarrval wrote: On 21/07/12 21:21, Kai Krueger wrote: On 07/21/2012 01:05 PM, Simone Cortesi wrote: Yes please, I would like to do the same too... -S On Sat, Jul 21, 2012 at 8:56 PM, Svavar Kjarrval sva...@kjarrval.is wrote: I want to make a similar routing table file for my country. Any chance of giving us instructions on how to generate such routing grids of our own? - Svavar Kjarrval I have now pushed the code I used to generate those tables to github. ( https://github.com/apmon/RoutingGrid ) It is a little java program that takes in a list of coordinates and city names and generates the html file for the routing grid. You can easily run it on your own list of coordinates / cities. Dennis, who is responsible for the OSRM server, was OK with me running the code against his server, and I suspect he wouldn't mind if others do the same. It uses Google's directions API as a reference, so it is subject to their terms. Currently they seem to allow 2500 requests per day, which would correspond to a maximum sized grid of 50 cities. It can cache the results from Google in a reference list, so you only need to query google once per city list. Kai Thanks a lot! I had an idea of a larger list of co-ordinates and could use this code to make a databased version. I'd probably have to host my own OSRM instance so I wouldn't bombard the main one with so many queries in a short time interval. OSRM really is amazingly fast (assuming you have a server with sufficient ram to convert the data into a routing db in the first place), so I don't see too much issue in principle in significantly expanding the routing grid. Calculating a route from New York to Los Angeles takes 500ms and that includes network round trip time across the Atlantic (ping time to the server from here is 150 ms). Depending on how far you want to expand it, you might even still be able to use the current instance, although you would have to ask Dennis about that. I was thinking about expanding the grid to every town in Iceland, which are at least 75. With Google's limit of 2500 queries a day, I'd have to make a program which makes regular queries and is careful about not going over that limit. And this is only the towns. This does not take into account addresses within them. Surely, I won't do this for every town as most of them are only a few streets but nontheless, it would generate a big queue of queries against Google. I don't know how the OSRM will react to such a large number of queries on a regular basis as I need to refresh the OSRM distances. If there is interest, I will try and expand the routing grid my self over the next couple of days, either to new countries or to more cities in a country. With the current code, the bigger short term issue is that it uses Google as a reference source and its limited allowance. However, once the routing problems are fixed again in OSM, there is no reason to not use a known good snapshot of OSM data as a reference in future and use it in quality assurance to check for any new broken routes. You could also use a snapshot from before the bot ran if you have access to it. Overall, this is really only a very small script that I hacked together in a couple of hours yesterday of which most of the time was spend in getting the coordinates for the cities list. So if you are planning to make too many changes, you might be better of writing it from scratch. It does give me ideas and I'll probably convert it anyway to another programming language. The command flow will give me neat ideas. It would be a kind of a quality assurance checker where I'd not only check links between cities/towns, but also links between some of the addresses inside them. Maybe add important POIs in the country as well. I really want the map to be of superior quality. You would likely need to go about it a bit different than to display routes in a grid (so the current code probably isn't a great basis), but the idea of automated quality control by generating a large set of routes between cities/towns/POIs has been floating around for quite a while. It is one of the reasons why there is still a debate about getting OSMF to operate a routing server itself to support these kind of QA checks. Personally, however, I suspect that an automated system will only every be able to check a fraction of the most prominent (and important) routes / roads and it will be more important to expose as many mappers as possible to the routing interface for them to try their own local routes for which they know the optimal solution. Kai - Svavar Kjarrval On 21/07/12 18:32, Kai Krueger wrote: Hello everyone, Inspired by the US 250 cities routing grid[1] used in the original TIGER cleanup in 2009, I have now created a similar routing grid for the USA and Australia. Australia:
Re: [OSM-talk] Very not happy
Peter, On 22 July 2012 09:27, Peter Wendorff wendo...@uni-paderborn.de wrote: Am 22.07.2012 00:42, schrieb andrzej zaborowski: If you're asking me (not Maetma 91), I think the problem has been known since the early days of OSMI license view (easily fixable too). For example this city I believe was showing as clean although it was a while since I have looked at that layer: http://osm.org/go/0MtRfiBy- Here's a before/after the bot run comparison someone made for that city: http://postimage.org/image/sv7gh0rkp/ http://postimage.org/image/8m60yvx8j/ First of all that's not the ID(s) Frederik asked for. Secondly: if it has been known to you - did you provide a patch or at least a patch idea for it? Wow, I wonder how people manage to ignore so many facts. First of all, I have not been silent about it, quite the opposite and the issue must have been known to Frederik because I remember he participated in one of the mailing list threads about it in mid 2011. Secondly no one could provide such a patch because no one knows what the bot is going to remove and what the LWG will deem clean or dirty, the real discussions about what will the bot do started on the rebuild list just a couple of months ago. So are you even serious about the patch suggestion? In this particular case I have been discussing this issue with Simon Poole of the LWG on IRC the day before the but ran (Tuesday last week) and in the morning he decided that the objects would stay and apparently later the same day changed his mind (I hope I'm not misrepresenting what happened, if I am, sorry). If it has been known before that there has been an error, then you cannot complain about it suddenly being deleted against the OSMI view - because obviously you knew about that already. Oh my, please re-read the conversation. I haven't been complaining, I was not a user of OSMI. I simply pointed out a gross error in somebody's statement. Someone said something that was incorrect and very ironic in face of how much people's hard work has been removed, all I said is that this was incorrect. Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Navit Map Conversion Warnings for Italy
Hello, I post here a number of warning I saw for Italy, when converting the map for navit: OSM Warning:http://www.openstreetmap.org/browse/relation/73035 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/87285 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/87286 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/104634 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/106389 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/106390 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/116839 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/116842 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/139179 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/149186 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/163277 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/165260 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/166062 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/166650 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/167710 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/184122 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/240760 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/269857 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/269995 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/269997 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/278289 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/286106 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/357251 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/365763 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/373729 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/383988 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/384649 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/399283 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/446249 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/446250 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/446808 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/536898 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/557868 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/557870 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/557874 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/570788 turn restriction: multiple via member OSM Warning:http://www.openstreetmap.org/browse/relation/898237 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/915395 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/930105 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/935777 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/945969 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/945970 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/945972 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/945973 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/957868 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/958993 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/958995 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/959003 turn restriction: to member
Re: [OSM-talk] Navit Map Conversion Warnings for Italy
Thanks, I've forwarded it to the italian list. On Sun, Jul 22, 2012 at 8:10 PM, Rainer Dorsch m...@bokomoko.de wrote: Hello, I post here a number of warning I saw for Italy, when converting the map for navit: OSM Warning:http://www.openstreetmap.org/browse/relation/73035 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/87285 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/87286 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/104634 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/106389 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/106390 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/116839 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/116842 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/139179 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/149186 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/163277 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/165260 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/166062 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/166650 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/167710 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/184122 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/240760 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/269857 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/269995 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/269997 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/278289 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/286106 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/357251 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/365763 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/373729 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/383988 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/384649 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/399283 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/446249 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/446250 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/446808 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/536898 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/557868 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/557870 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/557874 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/570788 turn restriction: multiple via member OSM Warning:http://www.openstreetmap.org/browse/relation/898237 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/915395 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/930105 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/935777 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/945969 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/945970 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/945972 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/945973 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/957868 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/958993 turn restriction: to member missing OSM
[OSM-talk] Re-mapping Hispanola = verifying that Haiti is ok, fixing Dominican Republic
*En francaise plus bas -- an kreyòl plis desann* --- Dear all, After a the license change bot ran over Hispanola and removed all edits incompatible with the new license there's a good amount of things to do, especially on the DR side to fix things. On the Haiti side we shouldn't have much damage but taken in consideration that OpenStreetMap is not only the best map of Haiti but also really the only good map it is critically important to verify that things are ok and fix where they are not. Thanks to Simon Poole setting up an installation of the H.O.T. developed Tasking Manager (Thanks to Pierre all!) I was able to set up sort of over view tasks for 1) Verifying that all of Haiti is ok (for the major parts): http://rebuild.poole.ch/job/20 , and 2) Fixing DR (for the road network): http://rebuild.poole.ch/job/19 . Please note that neither task's idea is to map everything in the task areas but merely to check that the road network (and perhaps major rivers) are ok and to fix anything that sticks out badly such as adding pieces of road that are clearly missing (and are part of the main road network. Also note that this is the first time I've used the Task Manager + created the tasks in 5 minutes, so I don't even claim that they would be well thought. .. All comments are more than welcome and I will tweak the tasks descriptions, etc as suited. Finally, especially for the DR side, the task areas are surely way too large in densly mapped (urban) areas. .. I will create separate tasks for those. (At least Santo Domingo). Cheers, -Jaakko http://osm.org/user/jaakkoh Ps. The tasking manager is only available currently in English as far as I know. And at least the descriptions of the task are only in English _currently_. All translation help is appreciated and I'll be happy to post/add any translations to the descriptions. *-- Francaise a la Google --* Bonjour à tous, Après un bot de la licence changement couru Hispanola et enlevé toutes les modifications incompatibles avec la nouvelle licence, il ya une bonne quantité de choses à faire, surtout sur le côté DR pour arranger les choses. Sur le côté Haïti, nous ne devrait pas avoir beaucoup de dégâts, mais pris en considération que OpenStreetMap est non seulement la meilleure carte de Haïti, mais aussi vraiment la seule carte bonne il est extrêmement important de vérifier que les choses sont ok et fixer où ils ne sont pas. Merci à Simon Poole mise en place d'une installation de la position HOT développé Gestionnaire Tasking (Merci à Pierre tout!), j'ai pu mettre en place sorte de «plus de vue des tâches pour 1) Vérifier que tous d'Haïti est ok (pour les pièces principales): http://rebuild.poole.ch/job/20 , et Fixation 2) DR (pour le réseau routier): http://rebuild.poole.ch/job/19 . S'il vous plaît noter que l'idée ni la tâche est de cartographier tout dans les domaines de travail, mais simplement de vérifier que le réseau routier (et peut-être les grands fleuves) sont ok et à réparer tout ce qui colle mal comme l'ajout d'éléments de route qui sont clairement portées disparues (et font partie du réseau routier principal. A noter également que c'est la première fois que j'ai utilisé le Gestionnaire des tâches + a créé les tâches en 5 minutes, donc je ne prétendent même pas qu'ils seraient bien pensé. .. Tous les commentaires sont plus que bienvenus et je vais modifier les tâches des descriptions, etc comme il convenait. Enfin, surtout pour le côté DR, les zones de travail sont certainement beaucoup trop grande dans densément cartographiés (urbaines). .. Je vais créer des tâches distinctes pour ceux-ci. (Au moins Santo Domingo). Cheers, Jaakko- http://osm.org/user/jaakkoh Ps. Le gestionnaire de tâches est uniquement disponible actuellement en anglais autant que je sache. Et au moins les descriptions de la tâche sont seulement en anglais _currently_. Tout aide à la traduction est apprécié et je serai heureux de publier / ajouter des traductions pour les descriptions. *-- Kreole a la Google --* Chè tout moun, Apre yon lisans bot nan chanjman kouri sou Hispanola ak retire tout edits enkonpatib ak lisans nan nouvo gen yon bon kantite lajan nan bagay yo fè, espesyalman sou bò DR ranje bagay sa yo. Sou bò Ayiti a nou pa ta dwe gen anpil domaj men yo te pran an konsiderasyon ke OpenStreetMap se pa sèlman kat jeyografik ki pi bon pou Ayiti, men tou vrèman kat la sèlman bon li se sevèman enpòtan w kapab verifye si bagay yo OK ak ranje kote yo pa yo. Gras a Simon Poole Mete kanpe yon enstalasyon nan cho a devlope Manadjè tach (Mèsi a Pierre tout!) mwen te kapab mete kanpe yon sòt de travay View sou pou 1) Verifye ke tout Ayiti se OK (pou pati ki pi gwo): http://rebuild.poole.ch/job/20, ak 2) fiksan DR (pou rezo a wout): http://rebuild.poole.ch/job/19. Tanpri note ke lide ni travay la se planifye tout bagay yo nan zòn travay, men senpleman yo tcheke ke rezo a wout (e petèt pi gwo rivyè) se OK ak ranje bagay ki kole soti seryezman tankou ajoute moso
Re: [OSM-talk] City routing grid for Australia and the US
On Sun, Jul 22, 2012 at 3:01 AM, Toby Murray toby.mur...@gmail.com wrote:
I already shared this on talk-us but since I have some degree of
worldwide coverage I guess I'll share it here too.
I noticed that the bot sometimes removed the highway=* tag but left
the oneway=* tag in place. At least here in the US, most such ways are
a part of the interstate system and since they are missing the highway
tag, greatly impact routing.
So I queried for ways with a oneway tag but no highway tag and put
them on a map. I am pre-rendering the tiles using Maperitive so
worldwide coverage only goes down to z10. I have added up to z13 in
some areas and will add more for higher density areas. I have already
done the UK, Spain/Portugal, some of France and the big cities in
Australia down to z13. You can see the map here:
http://ni.kwsn.net/~toby/OSM/maps/redaction.html
Or use it as a tile URL in JOSM:
tms:http://ni.kwsn.net/~toby/OSM/maps/oneway/{zoom}/{x}/{y}.png
I've been using this to guide my remapping efforts today and it is
indeed quite useful, even without high zoom levels. I did add z11 for
most of Europe though. I load it up in JOSM to find an area to edit.
Once I download data, it is usually pretty easy to pick out the way
that is missing its highway tag. It will be at the middle of the big
red blob from the tiles. But don't just fix the highway tag. I find
that where there is one way without a highway tag, there will usually
be other problems too like missing or disconnected _link roads or
missing bridges or the like.
Toby
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Very Happy - Looking forward
* 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 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [talk-au] Remapping assistance from the Philippines
Hi Michael/Ian, I've been reasonable active across Sydney yesterday and today as far as the Southern Highlands. There is quite a bit of stuff that can be put back together. I've only had to refer to my old traces and photos a couple of times. Good progress being made. All in all, I don't think it is quite as bad as I anticipated, and I think we can possibly be ahead of where we were in a few months (in Sydney at least) with some help :-) Of course there are few suburbs that will just need a comprehensive survey. I've done one or two this morning, and I'll enter them over the next couple of days. Ian. On 22 July 2012 15:29, Michael Hampson mhamp...@fastmail.com.au wrote: Thanks Ian, Post up here if you need any assistance. Anyone else in actively mapping around Sydney? Regards, Michael On 22/07/2012 2:11 PM, ianlopez wrote: Good afternoon, Australian OpenStreetMap contributors and other mailing list members. After viewing the current state of the map in the Sydney area, I've decided to help out in the remapping process. I'll initially remap roads, railways and some landuse in the Botany Bay area. Once done with the area, I'll work my way towards the international airport, Taren Point, Cronulla, Stanwell Park and areas in-between. If there are areas that need to be remapped, don't hesitate to send me a message. Tony Montana: Me, I want what's coming to me. Manny Ribera: Oh, well what's coming to you? Tony Montana: The world, chico, and everything in it. - Blog: http://ianlopez1115.wordpress.com/ OpenStreetMap/Twitter: ianlopez1115 Facebook: ian.lopez ___ Talk-au mailing listTalk-au@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-au ___ 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
Re: [talk-au] Redaction progress
On Thu, Jul 19, 2012 at 11:29 AM, waldo000...@gmail.com waldo000...@gmail.com wrote: Show of hands - Who's going to 1) stick around and help fix the Australian OSM map, and who's going to 2) jump ship and contribute to a fork (and if so, which one)? I'd love to stay with OSM but we gotta work together so inevitably I'll go with the majority... Thanks everyone for your responses. Seems like a great amount of interest still remains in fixing the OSM Australia map :-) Any Brisbane OSM mappers still around? ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Remapping assistance from the Philippines
On Sun, Jul 22, 2012 at 8:15 AM, Ian Sergeant inas66+...@gmail.com wrote: ... Of course there are few suburbs that will just need a comprehensive survey. I've done one or two this morning, and I'll enter them over the next couple of days. Just a reminder about Simon's task manager that might come in handy for coordinating these sort of tasks on a suburb level: http://rebuild.poole.ch/job/8 ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Redaction progress
Good to hear Peter!! I've already noticed some great work happening around Sydney. Things are improving day by day. :) Just waiting for the bot to hit my local area now. Regards, Michael On 22/07/2012 5:22 PM, Peter Watson wrote: Hi Guys, I'm sticking around, based Brisbane South. I have been putting back some Highways from memory, Bing and AGRI, There is considerable damage to many towns in QLD. Mackay has been removed and I think Bundaberg and Maryborough have been decimated also. PeterW34 ___ 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] REMAPPING: Shorelines on the NSW Central Coast
Hi all, Can anyone give me a heads-up as to how we've traditionally sourced coastlines for OSM? Actually, if it now differs due to licensing, then the best way forward - I'd like to re-establish the shores for Tuggerah Lakes as a starting point. Cheers, Paul. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Remapping assistance from the Philippines
If you are tracing from aerial imagery it would be a good idea to use rebuild.poole.ch to avoid conflicts. I'm looking for a volunteer to add more areas for Australia. Simon Am 22.07.2012 06:11, schrieb ianlopez: Good afternoon, Australian OpenStreetMap contributors and other mailing list members. After viewing the current state of the map in the Sydney area, I've decided to help out in the remapping process. I'll initially remap roads, railways and some landuse in the Botany Bay area. Once done with the area, I'll work my way towards the international airport, Taren Point, Cronulla, Stanwell Park and areas in-between. If there are areas that need to be remapped, don't hesitate to send me a message. Tony Montana: Me, I want what's coming to me. Manny Ribera: Oh, well what's coming to you? Tony Montana: The world, chico, and everything in it. - Blog: http://ianlopez1115.wordpress.com/ OpenStreetMap/Twitter: ianlopez1115 Facebook: ian.lopez ___ 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
Re: [talk-au] REMAPPING: Shorelines on the NSW Central Coast
The original coastlines were from PGS see - https://wiki.openstreetmap.org/wiki/Almien_coastlines_%28PGS%29 We then imported ABS2006 data, and some people aligned the coastlines to the suburb/town boundaries in that. In some parts of Australia these are accurate, in other parts not so much. This data was then adjusted in comparision to yahoo/nearmap/bing. We can import the ABS2011 data for the coastline section, if you really want to. I've done this for parts of Sydney Harbour and Georges River where it was quite accurate. However, for an area where hires imagery is available, I think it is fairly straightforward and more accurate to trace it. If there is a part that is badly damaged, perhaps add it to the rebuild task manager thing? Ian. On 22 July 2012 17:59, Paul HAYDON cadmana...@live.com.au wrote: Hi all, Can anyone give me a heads-up as to how we've traditionally sourced coastlines for OSM? Actually, if it now differs due to licensing, then the best way forward - I'd like to re-establish the shores for Tuggerah Lakes as a starting point. Cheers, Paul. ___ 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
Re: [talk-au] Remapping assistance from the Philippines
I'm hoping to restore some of Sydney's excellent cycle maps to their former glory. My previous edits were based on ways that got deleted. Some LGAs paint cycle routes on the road, but others just put up road signs. I'm hoping to find some of my old survey notes. From memory, councils that use signs only include Lane Cove, Hurstville and Kogarah. - Ben Kelley (Ebenezer) On Jul 22, 2012 4:15 PM, Ian Sergeant inas66+...@gmail.com wrote: Hi Michael/Ian, I've been reasonable active across Sydney yesterday and today as far as the Southern Highlands. There is quite a bit of stuff that can be put back together. I've only had to refer to my old traces and photos a couple of times. Good progress being made. All in all, I don't think it is quite as bad as I anticipated, and I think we can possibly be ahead of where we were in a few months (in Sydney at least) with some help :-) Of course there are few suburbs that will just need a comprehensive survey. I've done one or two this morning, and I'll enter them over the next couple of days. Ian. On 22 July 2012 15:29, Michael Hampson mhamp...@fastmail.com.au wrote: Thanks Ian, Post up here if you need any assistance. Anyone else in actively mapping around Sydney? Regards, Michael On 22/07/2012 2:11 PM, ianlopez wrote: Good afternoon, Australian OpenStreetMap contributors and other mailing list members. After viewing the current state of the map in the Sydney area, I've decided to help out in the remapping process. I'll initially remap roads, railways and some landuse in the Botany Bay area. Once done with the area, I'll work my way towards the international airport, Taren Point, Cronulla, Stanwell Park and areas in-between. If there are areas that need to be remapped, don't hesitate to send me a message. Tony Montana: Me, I want what's coming to me. Manny Ribera: Oh, well what's coming to you? Tony Montana: The world, chico, and everything in it. - Blog: http://ianlopez1115.wordpress.com/ OpenStreetMap/Twitter: ianlopez1115 Facebook: ian.lopez ___ Talk-au mailing listTalk-au@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-au ___ 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 mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] City routing grid for Australia and the US
On 22/07/12 09:31, Nick Hocking wrote: Excellent stuff Kai, Canberra-Adelaide will be underway soon. Right after Golf that is :-) Unfortunately, I know what's going to happen - I'll be zipping along the highways and will be sidetracked into fixing up every country town I pass that I have mapped in the past. I'll see if I make make it to Cootamundra tonight! I put Burley Griffin Way (Bowning - Wallendbeen section) back in a couple of days ago! I did most of Binalong a few weeks ago. There's still stuff to fix around Harden, and I haven't checked Coota. John ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] City routing grid for Australia and the US
I've done a bit of work on the Hume Freeway / Highway tonight and it's not in too bad shape. The main problem area is around Yass. I haven't worked further north than that yet. Hopefully it's not too far from being able to turn the Melbourne - Sydney grid green again. On Sun, Jul 22, 2012 at 2:26 PM, John Henderson snow...@gmx.com wrote: On 22/07/12 09:31, Nick Hocking wrote: Excellent stuff Kai, Canberra-Adelaide will be underway soon. Right after Golf that is :-) Unfortunately, I know what's going to happen - I'll be zipping along the highways and will be sidetracked into fixing up every country town I pass that I have mapped in the past. I'll see if I make make it to Cootamundra tonight! I put Burley Griffin Way (Bowning - Wallendbeen section) back in a couple of days ago! I did most of Binalong a few weeks ago. There's still stuff to fix around Harden, and I haven't checked Coota. John __**_ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-auhttp://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[talk-au] Getting back into it
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
Re: [talk-au] OSRM A few basic questions
Am 22.07.2012 01:51, schrieb Brett Russell: Hi A few things. 1. I used Polatch 2 to add a house and give it an address. I chose the last house in Oldaker Street Devonport with the number 237. How do I link the house to the street? Add addr:street to the house (either building outline or the node). 2. I then used OSRM to find the route from Oldaker Street, Devonport to George Street Launceston. It gives me the option to select Oldaker in Burnie or Devonport but not George Street in Launceston. Thinks Canada is a nice place to be. OSRM uses nominatim to do address lookups, nominatim is currently (due to the redaction process) not being updated. As soon as we have a new ODBL licenced planet the nominatim database will be reloaded and we will have very fast updates again (and there should be substantially less issues with place nodes). 3. So I type in George Street, Launceston and it decides I must be heading to George Street in Longford. Basically what I am trying to do is test the routing to find and fix broken routes. The questions are rather newbie but OSM help and search brings up countless opinions like you should be using JOSM wi8th X or Y plugin (ok I have more than one computer and installing JOSM on everyone including friends makes no sense). All I am after at this stage is a simple means to test a route and fix it up. Right now I would simply test routes between stuff that survived the redaction. I assume that I need to split roads and give each section a different speed limit when it changes. Yes. Simon ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Redaction progress
Yeah, I'm working on it - up in the northern suburbs at the moment, it's the area I know best. It's interesting that many streets that were showing as OK in the tools prior to the change may still be there, but are missing many nodes, so they don't match reality any more. I find you have to actually check right along a road, don't just assume if it's still there it's OK. Unfortunately, it's a really busy time of the year for me, so I don't have as much time as it really needs. But I can see I'll be working on the noname fixing again when I get some free time. Stephen On 22 July 2012 16:36, waldo000...@gmail.com waldo000...@gmail.com wrote: Thanks everyone for your responses. Seems like a great amount of interest still remains in fixing the OSM Australia map :-) Any Brisbane OSM mappers still around? ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [Talk-is] Gögn sem hurfu fyrir Mosfellsbæ
Held það sé best að spyrja á almenna póstlistanum hvernig á að höndla þetta. 2012/7/21 Svavar Kjarrval sva...@kjarrval.is: Veit ekki betur en að setja þurfi inn gögnin aftur inn sérstaklega. Efast um að það gerist sjálfkrafa. - Svavar Kjarrval On 21/07/12 17:50, bald...@baldvin.com wrote: Hef haft samband beint við DouglasAtEik og hann sagði mér að það væri bara athugunarleysi að vera ekki búinn að samþykkja nýja leyfið. Sagði mér jafnframt að hann ætlaði að gera það hið fyrsta og bað mig að senda sér upplýsingar um það hvernig það væri gert. Ég benti honum á að skrá sig inn á sína síðu og þetta væri aðgengilegt þar, ef ég man rétt. Ef þið hafið nánari upplýsingar þá mættuð þið endilega miðla þeim hér. Ég hef ekki fundið þetta sagt beinum orðum en ég er að vona að gögn sem voru felld út komi aftur inn eftir að hann hefur samþykkt þetta? Veit einhver hvernig það virkar? mbk, Baldvin ___ 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-de] OSM warning in navit map generation (Baden-Wuerttemberg)
Hello, I got some warnings in the navit map conversion process for Baden- Wuerttemberg. In case it is not useful, please let me know, and I will not post again theses kind of data turn restrictions: OSM Warning:http://www.openstreetmap.org/browse/relation/14513 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/14514 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/49832 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/139010 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/286579 turn restriction: multiple via member OSM Warning:http://www.openstreetmap.org/browse/relation/287329 turn restriction: multiple via member OSM Warning:http://www.openstreetmap.org/browse/relation/309667 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/386372 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/387016 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/387017 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/387018 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/387019 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/537013 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/931861 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/931868 turn restriction: multiple via member OSM Warning:http://www.openstreetmap.org/browse/relation/1083522 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1140728 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1205863 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1261837 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1371268 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1375654 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1375655 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1397371 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1663158 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1663265 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1796918 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/1830532 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1936209 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/1965464 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1967770 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/2086710 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2088552 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2124581 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2125551 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2125556 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2127399 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2127400 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2225347 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2248138 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2265093 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2274083 turn restriction: from member missing ways phase OSM Warning:http://www.openstreetmap.org/browse/way/26281268 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/30248605 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/33514160 Broken polygon, area is 0 OSM Warning:http://www.openstreetmap.org/browse/way/34293887 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/52513873 Broken polygon, less than 3 points defined OSM
Re: [Talk-de] Zurueck in die Steinzeit
aighes-2 wrote ..Viel zu kompliziert...bei einer Anfahrtskizze tut es schon ein Screenshot der Karte. Klar, in diesem Falle eine gute, machbare Lösung. Ich bin in meinem netten Kommentar auch davon ausgegangen, dass es sich wirklich nur um eine kleine Anfahrtskizze handelt - da wäre ein eigener Server wohl etwa oversized. Wenn aber auf dieser kleine Skizze Sachen fehlen (bot) oder falsch sind, könnte der Hauptbenutzer seine Ecke schon ein wenig pflegen. Kriegt der Enkel auch ohne Josm hin ;) Ein Screenshot hilf *jetzt* natürlich wenig. Gruss Walter -- View this message in context: http://gis.19327.n5.nabble.com/Zurueck-in-die-Steinzeit-tp5716989p5717792.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] OSM warning in navit map generation (Baden-Wuerttemberg)
Am 22.07.2012 10:05, schrieb Rainer Dorsch: Hello, I got some warnings in the navit map conversion process for Baden- Wuerttemberg. In case it is not useful, please let me know, and I will not post again theses kind of data turn restrictions: Hi, nützlich wäre es noch zu wissen ob Du hier Post- oder Pre-Redaction Data verarbeitet hast... ;-) Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM warning in navit map generation (Baden-Wuerttemberg)
Am Sonntag, den 22.07.2012, 12:27 +0200 schrieb Chris66: Am 22.07.2012 10:05, schrieb Rainer Dorsch: Hello, I got some warnings in the navit map conversion process for Baden- Wuerttemberg. In case it is not useful, please let me know, and I will not post again theses kind of data turn restrictions: Hi, nützlich wäre es noch zu wissen ob Du hier Post- oder Pre-Redaction Data verarbeitet hast... ;-) Chris Hi, ist doch eigentlich egal. Bei den ersten beiden wurde doch beim letzten Edit von bigboss die from - rules entfernt, weil er den Weg gelöscht hat. Oder tarnt sich so jetzt der Redaction-Bot?? ;-)) Jörg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM warning in navit map generation (Baden-Wuerttemberg)
Am Sunday 22 July 2012 schrieb Jörg Frings-Fürst: Am Sonntag, den 22.07.2012, 12:27 +0200 schrieb Chris66: Am 22.07.2012 10:05, schrieb Rainer Dorsch: Hello, I got some warnings in the navit map conversion process for Baden- Wuerttemberg. In case it is not useful, please let me know, and I will not post again theses kind of data turn restrictions: Hi, nützlich wäre es noch zu wissen ob Du hier Post- oder Pre-Redaction Data verarbeitet hast... ;-) Chris Hi, ist doch eigentlich egal. Bei den ersten beiden wurde doch beim letzten Edit von bigboss die from - rules entfernt, weil er den Weg gelöscht hat. Oder tarnt sich so jetzt der Redaction-Bot?? ;-)) Hallo, die Daten habe ich von http://download.geofabrik.de/osm/europe/germany/baden-wuerttemberg.osm.bz2 heute morgen gezogen. Bin nicht sich, wann der Bot lief/läuft. Danke und Gruß Rainer -- Rainer Dorsch http://bokomoko.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSM Warnungen beim Erzeugen einer Navit Karte (Bayern)
Hallo, hier die äquivalenten Warnungen für die Karte von Bayern: Turn relations: OSM Warning:http://www.openstreetmap.org/browse/relation/59134 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/59145 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/104598 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/142128 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/160853 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/160854 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/272268 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/372902 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/372903 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/419133 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/443898 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/448952 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/962893 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/324 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/1210983 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1210990 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1283234 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1389766 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1413735 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1436728 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1436729 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1436730 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1659670 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1664369 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/1672888 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1694364 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1838433 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1838437 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1958873 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1964615 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2008304 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/2017124 turn restriction: multiple via member OSM Warning:http://www.openstreetmap.org/browse/relation/2026076 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2026907 turn restriction: multiple via member OSM Warning:http://www.openstreetmap.org/browse/relation/2047728 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2047729 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2048371 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/2076363 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2080660 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2119351 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2173224 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/2273793 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2280169 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2282465 turn restriction: via member missing Polygone: OSM Warning:http://www.openstreetmap.org/browse/way/24897296 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/25660084 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/28149073 Broken polygon, area is 0 OSM Warning:http://www.openstreetmap.org/browse/way/28236618 Broken
Re: [Talk-de] OSM warning in navit map generation (Baden-Wuerttemberg)
Am 22.07.2012 12:27, schrieb Chris66: Am 22.07.2012 10:05, schrieb Rainer Dorsch: Hello, I got some warnings in the navit map conversion process for Baden- Wuerttemberg. In case it is not useful, please let me know, and I will not post again theses kind of data turn restrictions: Hi, nützlich wäre es noch zu wissen ob Du hier Post- oder Pre-Redaction Data verarbeitet hast... ;-) Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Eigentlich egal, so und so gehört der Fehler behoben. LG Jimmy PS: Ich halte die Daten für nützlich. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM warning in navit map generation (Baden-Wuerttemberg)
On 22/07/12 17:32, Jimmy_K wrote: Am 22.07.2012 12:27, schrieb Chris66: Am 22.07.2012 10:05, schrieb Rainer Dorsch: Hello, I got some warnings in the navit map conversion process for Baden- Wuerttemberg. In case it is not useful, please let me know, and I will not post again theses kind of data turn restrictions: Hi, nützlich wäre es noch zu wissen ob Du hier Post- oder Pre-Redaction Data verarbeitet hast... ;-) Chris Eigentlich egal, so und so gehört der Fehler behoben. +1 LG Jimmy PS: Ich halte die Daten für nützlich. Ich auch und habe begonnen die Abbiege-Relationen von unten nach oben zu reparieren. Die meisten welche ich nicht reparieren kann sind user faults Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Warnungen beim Erzeugen einer Navit Karte (Österreich)
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 -- Rainer Dorsch http://bokomoko.de/ ___ 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)
Hallo Reiner, bin in talk-cz drin, falls es Ähnliches für die Tschechei gibt, kann es einfach weiterleiten. On Sun, Jul 22, 2012 at 8:25 PM, Rainer Dorsch m...@bokomoko.de wrote: 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 -- Rainer Dorsch http://bokomoko.de/ ___ 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] Zurueck in die Steinzeit
Bernd Wurst wrote: Kannst Du Dir vorstellen das es neben auf dem Egotrip sein für Jeden individuell verschiedene und sachlich begründete Fakten gab die ihn von der Zustimmung abhielten? Da Importe von Drittdaten normalerweise immer unter einem dafür angelegten Benutzernamen gemacht wurden und daher jeder natürliche Benutzer auch wirklich die Rechte an seinen Änderungen hält: Eigentlich nicht. Mir ging es nicht um Importe. Ich meinte mehr das sich möglicherweise Mapper ganz bewußt gegen die Lizenzänderung aussprechen und dafür individuelle Gründe haben, die wir beide nicht kennen. Das, was es hier zerhauen hat, kann ich sogar mit hoher Warscheinlichkeit einem sehr frühen Mapper zuordnen. Der hat hier studiert und die halbe Stadt ganz alleine gemacht. Danach hat ihn OSM wohl nicht mehr interessiert, die Lizenzgeschichte dürfte komplett an ihm vorbei gegangen sein. Egotrips sind das nicht. Straßen hängen komplett in der Luft. Plural? Es war eine. Und die ways waren noch da, nur ohne Tags. Ich habe die Tags wieder dran gepappt. Ja, das war mehr es sieht hier an vielen Stellen so aus. Egal, Du hast es repariert, danke. Da war wohl jemand schneller. Ich sehe da keine Probleme. Es hat an allen von mir genannten Stellen der immer gleiche User gearbeitet und wenn ich in dessen Bearbeitungshistorie schaue hoffe ich, er kennt sich in ganz Deutschland tatsächlich so gut aus wie seine Edits erkennen lassen... Die Wege bzw. ihre Nodes waren vorhanden, habe residentials draus gemacht. Könntest du mit deiner Ortskenntnis bitte noch die Straßennamen eintragen? Ja, aber nicht sofort und nicht die nächsten Wochen. Ich muß da _hin_ und das Schild ablesen. So klein sind wir hier nicht, dass ich jeden Straßennamen kenne. Die Paul-Jäkel-Straße hat der Bot verhauen, die Erzberger Straße sieht wegen einsturzgefährdeter Brücke tatsächlich so aus! Jetzt warte ich schon gespannt wann der erste Bing-Mapper kommt und repariert. Und dann auf den Nächsten, der das korrigiert. Bis wieder ein Bing-Mapper kommt und repariert, weil es doch so nach dem typischen Bot-löschen aussieht. Nun, das kann man ganz einfach beheben, indem man die Brücke (die laut deiner Aussage ja im Prinzip noch da ist) einfach einträgt als gesperrt. Durch die schon vorhandenen noexit-tags war das deutlich zu sehen wie du es beschrieben hast, ich hab die Brücke jetzt noch eingetragen. Und die Paul-Jäkel-Straße habe ich auch repariert. Ja, das war jetzt so einfach weil Du die Daten von mir hattest. Ich stieß mich an Deiner Aussage, das sei alles problemlos mit Bing zu reparieren. Dann hast du ja bestimmt deine Aufzeichnungen noch. Da kann ich am Luftbild nicht erkennen wie das sein sollte. Ähm, nein. ich weiß nicht wie andere Mapper arbeiten. Ich fahre da hin, habe dann einen GPX-Track, mache ggf. paar Bilder von Straßenschildern usw. Wenn ich das alles eingegeben habe sind Fotos von Straßenschildern jetzt nicht so von weiterem Wert für mich und ich lösche das. Die GPX-Daten liegen ganz sicher mit chronologischem Dateinamen hier rum, aber ich merke mir nicht wann ich wo war und was ich danach dort editiert habe. Auf die Idee das meine Daten derartige Löschorgien überstehen müssen bin ich damals nicht gekommen. Ist halt die Frage des Anspruchs. Klar, viele Attribute, Oberflächenbeschreibungen und so sind super. Werden aber momentan nicht wirklich irgendwo benutzt. Schau mal in die Stylefiles der MTBMap oder der Velomap... Und wer noch alles diese Daten benutzt hat wissen wir gar nicht. Natürlich hast Du Recht, rudimentäres Routing ist auch ohne surface=asphalt usw. drin. aktualisiert nutzt dann in ein paar Tagen wieder den korrigierten Bestand. Den Optimismus teile ich nicht. IMHO werden es wohl eher Monate werden. Die, die den Götz von Berlichingen machen und nie wieder aktiv werden weil sie mit diesem Umgang mit der Arbeit, die sie in ihrer Freizeit leisteten, nicht einverstanden sind, noch gar nicht mitgerechnet. 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
[Talk-de] Warnungen beim Erzeugen einer Navit Karte (Schweiz)
Hallo, hier die Warnungen für die Schweiz: turn restrictions: OSM Warning:http://www.openstreetmap.org/browse/relation/169051 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/169052 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/169053 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/410435 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/043 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1300520 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1300522 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1300523 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1300524 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1300525 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1342961 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1756112 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1832623 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2082534 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2082535 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2266273 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2296937 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/1853786 turn restriction: from member not found OSM Warning:http://www.openstreetmap.org/browse/relation/2019001 turn restriction: from member not found polygon Warnungen: OSM Warning:http://www.openstreetmap.org/browse/way/38696067 Broken polygon, area is 0 OSM Warning:http://www.openstreetmap.org/browse/way/50759439 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/50760438 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/159742530 Broken polygon, less than 3 points defined -- Rainer Dorsch Lärchenstr. 6 D-72135 Dettenhausen 07157-734133 email: rdor...@web.de jabber: rdor...@jabber.org GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E Full GPG key: http://pgp.mit.edu/ -- Rainer Dorsch http://bokomoko.de/ ___ 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)
Könnt ihr das bitte mal sein lassen, diese Fehler alle hier zu posten. Die allermeisten Leute auf dieser Liste interessiert das nicht die Bohne. Wenns sein muss, macht halt ne Wiki-Seite oder findet sonst einen Platz dafür. Jochen On Sun, Jul 22, 2012 at 09:03:22PM +0200, Rainer Dorsch wrote: Date: Sun, 22 Jul 2012 21:03:22 +0200 From: Rainer Dorsch m...@bokomoko.de To: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Subject: [Talk-de] Warnungen beim Erzeugen einer Navit Karte (Schweiz) Hallo, hier die Warnungen für die Schweiz: turn restrictions: OSM Warning:http://www.openstreetmap.org/browse/relation/169051 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/169052 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/169053 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/410435 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/043 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1300520 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1300522 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1300523 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1300524 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1300525 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1342961 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1756112 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1832623 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2082534 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2082535 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2266273 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2296937 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/1853786 turn restriction: from member not found OSM Warning:http://www.openstreetmap.org/browse/relation/2019001 turn restriction: from member not found polygon Warnungen: OSM Warning:http://www.openstreetmap.org/browse/way/38696067 Broken polygon, area is 0 OSM Warning:http://www.openstreetmap.org/browse/way/50759439 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/50760438 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/159742530 Broken polygon, less than 3 points defined -- Rainer Dorsch Lärchenstr. 6 D-72135 Dettenhausen 07157-734133 email: rdor...@web.de jabber: rdor...@jabber.org GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E Full GPG key: http://pgp.mit.edu/ -- Rainer Dorsch http://bokomoko.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- 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
[Talk-de] Permanente/stabile OSM IDs!
Hallo Mich beschäftigt seit einiger Zeit die Frage von permanenten/stabilen OSM IDs und der Verknüpfung von OSM mit anderen Datenbanken. 2012/7/22 Sarah Hoffmann lon...@denofr.de schrieb in einer Diskussion auf talk-ch: On Sun, Jul 22, 2012 at 01:40:48PM +0200, Stefan Keller wrote: ... What remains to me is the following, since I'm having in mind OSM which is more and more related to external databases. First, I'm still convinced that the principle of update (versus delete and recreate) should hold also for OSM. Second, we seem to have a problem with stable id's in OSM (osm_id). Having external id's in OSM now seems to me like a necessity (in order to become related to external dbs) and a concession to the fact the OSM doesn't have stable ids. At least it's also an indication or flag to OSM users. One of the big TODOs of OSM. Closest thing we have at the moment is Rolands proposal base on the Overpass API: http://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID Problem is that it is pretty hard to define what is 'stable' in the context of OSM. How should splitting of ways be handled? What if a shop moves to the next building? What if we split the bus stops into two, one for each direction? So, we actually end up with a n-to-n relation: one OSM object might have multiple UIDs (for the shop, for the building, for the address...) and a UID might reference multiple OSM objects (split ways). Sarah 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. Wenn nur die Way Tags ändern, dann sind sich hoffentlich alle einig, dass deswegen keine neue Way ID erzeugt wird. Wird ein Way geometrisch verlängert oder ein Node eingefügt, dann hoffentlich auch nicht! Im oben erwähnten Fall wird ein - zunächst als ein bus_stop erfasste - Busstation in zwei bus_stops aufgeteilt, weil das eher der Realität entspricht. Oder es wird ein Way gesplittet wird (wenigstens bleibt dann die ID typischerweise erhalten). In diesen Fällen lässt sich auch mit nicht-technischen Argumenten debattieren, ob das nun ein Update oder ein Delete/Create ist! Daher: 2. OSM ID's sind grundsätzlich stabil! Wenn ich mir diese Beispiele anschaue - und annehme, dass Tools (wie JOSM) korrekt arbeiten und richtig angewendet werden -, dann sehe ich keinen Anlass, die OSM ID's grundsätzlich als instabil zu bezeichnen. Ich lasse mich aber gern - bzw. weils's sein muss :- vom Gegenteil überzeugen. 3. Projekt-ID Tag als Lösung? 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. Es kommen immer wieder Fälle vor, wo eine ID ungewollt untergeht und wo man als OSM-externe Datenbank (z.B. als Projekt wie http://wiki.openstreetmap.org/wiki/OpenMetaMap ) dann situativ darauf reagieren muss. Fälle wie der Lizenzwechsel müssen sowieso separat gelöst werden. Es kann auch vorkommen, dass am (zu einer ID kombinierten) Tag network=BAB+ref=A 516 etwas geschieht, z.B. wenn ein jemand (inkl. ein Tool) findet, ref=A 516 sei doch ref=A516 - also A516 ohne Space! Das Problem solcher eindeutigen Eigenschaften eines Objekts scheint mir, dass solch sprechende IDs nichts taugen - und es ist erst noch nicht an den Keynamen network+ref erkenntlich, dass sie überhaupt IDs bilden. Das ist genau der Unterschied zwischen Schlüssel und Identifikator! Mir scheint nichts anderes übrig zu bleiben, als entweder mit der OSM ID zu leben (und deren Stabilität laufend zu verbessern!) - oder aber folgendes: 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. D.h. keine Kombination und keine normal aussehende Keys, sondern einen einzigen in OSM klar als ID erkennbaren Key. Der feine Unterschied zu network+ref
Re: [Talk-de] Warnungen beim Erzeugen einer Navit Karte (Schweiz)
Am Sunday 22 July 2012 schrieb Jochen Topf: Könnt ihr das bitte mal sein lassen, diese Fehler alle hier zu posten. Die allermeisten Leute auf dieser Liste interessiert das nicht die Bohne. Wenns sein muss, macht halt ne Wiki-Seite oder findet sonst einen Platz dafür. Jochen, entschuldige, aber kein Grund zur Sorge, ich habe keine weiteren Daten mehr :-) Da einige Leute Interesse an den Daten gezeigt haben, werde ich sie wenn immer ich welche habe (erwarte etwa alle 2 Monate im Schnitt) zur Verfügung stellen. Ich werde eine Summary-Mail mit Links schicken, anstelle von den Einzelmails. Viele Grüße Rainer -- Rainer Dorsch http://bokomoko.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Hi Stefan, Stefan Keller schrieb: Mich beschäftigt seit einiger Zeit die Frage von permanenten/stabilen OSM IDs und der Verknüpfung von OSM mit anderen Datenbanken. ich denke du suchst sowas in der Art, oder? Dauerhafte Links nach OSM - Overpass API http://blog.openstreetmap.de/2012/03/dauerhafte-links-nach-osm/ viele gruesse pascal ___ 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 22.07.2012 21:25, schrieb Rainer Dorsch: Am Sunday 22 July 2012 schrieb Jochen Topf: Könnt ihr das bitte mal sein lassen, diese Fehler alle hier zu posten. Die allermeisten Leute auf dieser Liste interessiert das nicht die Bohne. Wenns sein muss, macht halt ne Wiki-Seite oder findet sonst einen Platz dafür. Jochen, entschuldige, aber kein Grund zur Sorge, ich habe keine weiteren Daten mehr :-) Da einige Leute Interesse an den Daten gezeigt haben, werde ich sie wenn immer ich welche habe (erwarte etwa alle 2 Monate im Schnitt) zur Verfügung stellen. Ich werde eine Summary-Mail mit Links schicken, anstelle von den Einzelmails. 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. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Ich würde auch ein Tag wie ref:myproject=(foreign key) benutzen. Ich habe vor einige Tage aber irgendwo gelesen dass das auch nicht gewunscht sei. Polyglot ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] GPX-Dateien wiederfinden (was: Zurueck in die Steinzeit)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22.07.2012 20:50, Joerg Fischer wrote: Die GPX-Daten liegen ganz sicher mit chronologischem Dateinamen hier rum, aber ich merke mir nicht wann ich wo war und was ich danach dort editiert habe. Hallo Jörg, 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.) Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlAMXDcACgkQnMz9fgzDSqd41ACfTGo0NKTg1MNKcc/h767mHKNo c3oAn2uhqHz4rXEWG4bSwHrMBX9rwwCN =d7k0 -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zurueck in die Steinzeit
Am 22.07.2012 20:50, schrieb Joerg Fischer: Bernd Wurst wrote: Ist halt die Frage des Anspruchs. Klar, viele Attribute, Oberflächenbeschreibungen und so sind super. Werden aber momentan nicht wirklich irgendwo benutzt. Schau mal in die Stylefiles der MTBMap oder der Velomap... Und wer noch alles diese Daten benutzt hat wissen wir gar nicht. Natürlich hast Du Recht, rudimentäres Routing ist auch ohne surface=asphalt usw. drin. Ack aktualisiert nutzt dann in ein paar Tagen wieder den korrigierten Bestand. Den Optimismus teile ich nicht. IMHO werden es wohl eher Monate werden. Die, die den Götz von Berlichingen machen und nie wieder aktiv werden weil sie mit diesem Umgang mit der Arbeit, die sie in ihrer Freizeit leisteten, nicht einverstanden sind, noch gar nicht mitgerechnet. Den Götz mache ich gar nicht. Aber in der Zeit, als hier in der Gegend OSM im wesentlichen aus ein paar (oft fehlerhaften) Durchgangsstraßen und Autobahnen bestand, habe ich etliche Tankfüllungen vergurkt, mich in Schneewehen festgefahren und manches mal geschwitzt, daß mich keiner anmoppert, weil ich auch mal diverse Zufahrtsbeschränkungen ignoriert habe. Hatte ja ein Anliegen :-) Das tue ich mir nicht nochmal von vorne an. -- Rainer ___ 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 21:38, schrieb Jo: Ich würde auch ein Tag wie ref:myproject=(foreign key) benutzen. Ich habe vor einige Tage aber irgendwo gelesen dass das auch nicht gewunscht sei. Das ist ja nun auch großer Käse...wie viel Anwendungen gibt es, die mit OSM-Daten arbeiten...Wo soll das enden, wenn jede Anwendung irgendwelche spezifischen Tags an Objekte hängt? Und was bringt es, wenn jemand das Objekt mit samt dem raf-Tag löscht und ein neues ohne all die ref-Tags erstellt? 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. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
schau dir mal die sache mit den uuids an. ich glaube, dass das ein interessanter Ansatz ist. https://wiki.openstreetmap.org/wiki/Proposed_Features/UUID von diesem thread find ich gerade nicht den anfang: http://www.mail-archive.com/talk@openstreetmap.org/msg30181.html uuid für osm geistert schon lange bei uns rum, ist aber irgendwie eingeschlafen. Gruss walter p.s. sorry, bin gerade knapp dran mit zeit. -- View this message in context: http://gis.19327.n5.nabble.com/Permanente-stabile-OSM-IDs-tp5717856p5717870.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] Permanente/stabile OSM IDs!
Hallo Stefan. Ich glaube, du hast dir da direkt ein schwierigeres Thema rausgesucht - und ich hab dazu sicher auch keine perfekte Lösung. Den Ansatz der Overpass-API hast du ja schon mit aufgelistet, und ich halte ihn für momentan den am ehesten praxistauglichen. Deine anderen Ideen kritisiere (bitte nicht übelnehmen) ich mal zwischen deinem Text: Am 22.07.2012 21:22, schrieb Stefan Keller: 1. Sind OSM ID's wirklich instabil? bzw. Wann ändern IDs ungewollt/unfreiwillig? Nehmen wir an, ich trage einen Supermarkt als Node ein - ein gängiger Weg, wenn ich keine Luftbilder zur Verfügung habe. Beim Hochladen bekommt dieser Supermarkt die Id node 42 - denn osm hat ja für nodes, ways und relations getrennte id-räume. Jetzt kommst du und hast 'n Luftbild, willst den supermarkt also besser eintragen als Polygon: Wenn/da du weißt, dass ids zum verlinken genutzt werden könnten, benutzt du den alten node als startknoten des gebäudepolygons und kopierst die daten auf das polygon. Der way hat jetzt eine ID way23 - und die id node42 kann er auch gar nicht kriegen, das hat mit dem editor nichts zu tun. Wenn eine Software aber zur ID node42 verlinkt, wird er z.B. die Öffnungszeiten nicht mehr finden können, denn die hängen jetzt korrekterweise am way23. Eine Korrektur hin zu stabilen ObjektIDs ist also mit der aktuellen API nicht machbar - und vermutlich auch so ohne weiteres dauerhaft nicht zu lösen, denn: - Ich trage das Gebäude Mozartstraße 3 als Polygon way323 ein mit building=yes, amenity=doctors. - Eine Datenbank D verlinkt das Gebäude (way323), um die Arztpraxis von Dr. OSM zu markieren. - Du verbesserst OSM und trägst die drei Arztpraxen von Dr. OSM, Dr. Etsch und Dr. doofe-IDee als einzelne nodes ein. Auf einmal ist zwar das ursprüngliche polygon noch da, aber das ist gar nicht das, was die externe datenbank meinte - die verlinkt immer noch zum damals am besten passenden Objekt. Das war zwar vorher schon eine Arztpraxis, aber eben noch ungenau, die drei arztpraxen wurden als eine abgebildet. 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 stimmt nicht, wenn du den node nur verschiebst. Dafür musst du ihn kopieren und einfügen. Das ist aber kein logisch zwingender Grund, sondern technischer Mangel. Nein. Nur eine andere Interpretation dessen, was richtig ist, als du sie annimmst. Wenn nur die Way Tags ändern, dann sind sich hoffentlich alle einig, dass deswegen keine neue Way ID erzeugt wird. Wird ein Way geometrisch verlängert oder ein Node eingefügt, dann hoffentlich auch nicht! Im Sinne stabiler IDs: Wenn ein way das Tag highway=residential verliert und jetzt auf einmal stattdessen building=yes bekommt, dann ist das ein neues Objekt. Wenn dagegen highway=residential durch highway=pedestrian ausgetauscht wird, ist die Straße im Grunde die gleiche geblieben. 2. OSM ID's sind grundsätzlich stabil! Wenn ich mir diese Beispiele anschaue - und annehme, dass Tools (wie JOSM) korrekt arbeiten und richtig angewendet werden -, dann sehe ich keinen Anlass, die OSM ID's grundsätzlich als instabil zu bezeichnen. Ich lasse mich aber gern - bzw. weils's sein muss :- vom Gegenteil überzeugen. Guck dir alle Städte an, die bisher noch Hausnummern in Form von Nodes enthalten, verschaff denen aktive Mapper mit etwas Langeweile und gute Luftbilder - und schon sind deine alten Nodes weg und unter neuen IDs die gleichen Hausnummern in Form von Gebäudepolygonen drin - tausendfach. 3. Projekt-ID Tag als Lösung? 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. Es kommen immer wieder Fälle vor, wo eine ID ungewollt untergeht und wo man als OSM-externe Datenbank (z.B. als Projekt wie http://wiki.openstreetmap.org/wiki/OpenMetaMap ) dann situativ darauf reagieren muss. Fälle wie der Lizenzwechsel müssen sowieso separat gelöst werden. Es kann auch vorkommen, dass am (zu einer ID kombinierten) Tag network=BAB+ref=A 516 etwas geschieht, z.B. wenn ein jemand (inkl. ein Tool) findet, ref=A 516 sei doch ref=A516 - also A516 ohne Space! Das Problem solcher eindeutigen Eigenschaften eines Objekts scheint mir, dass solch sprechende IDs nichts taugen - und es ist erst noch nicht an den Keynamen network+ref erkenntlich, dass sie überhaupt IDs bilden. Das ist genau der Unterschied zwischen Schlüssel und Identifikator! Die stabile ID, die die overpass-ID einführt, ist eben keine ID im eigentlichen Sinne, sondern eine
Re: [Talk-de] Warnungen beim Erzeugen einer Navit Karte (Schweiz)
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. 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 Pascal Am 22. Juli 2012 21:30 schrieb Pascal Neis pascal.n...@gmail.com: Hi Stefan, Stefan Keller schrieb: Mich beschäftigt seit einiger Zeit die Frage von permanenten/stabilen OSM IDs und der Verknüpfung von OSM mit anderen Datenbanken. ich denke du suchst sowas in der Art, oder? Dauerhafte Links nach OSM - Overpass API http://blog.openstreetmap.de/2012/03/dauerhafte-links-nach-osm/ Jein; das Problem dieses Vorschlags ist, dass er zusammengesetzte, z.T. sprechende Schlüssel vorschlägt. Vgl. meine Ausführungen unten. LG, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Nur mal zum über den Hag schauen: http://en.wikipedia.org/wiki/TOID Am 22.07.2012 22:19, schrieb Walter Nordmann: schau dir mal die sache mit den uuids an. ich glaube, dass das ein interessanter Ansatz ist. https://wiki.openstreetmap.org/wiki/Proposed_Features/UUID von diesem thread find ich gerade nicht den anfang: http://www.mail-archive.com/talk@openstreetmap.org/msg30181.html uuid für osm geistert schon lange bei uns rum, ist aber irgendwie eingeschlafen. Gruss walter p.s. sorry, bin gerade knapp dran mit zeit. -- View this message in context: http://gis.19327.n5.nabble.com/Permanente-stabile-OSM-IDs-tp5717856p5717870.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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Hallo Jo/aighes und Henning Am 22. Juli 2012 22:14 schrieb aighes o...@aighes.de: Am 22.07.2012 21:38, schrieb Jo: Ich würde auch ein Tag wie ref:myproject=(foreign key) benutzen. Ich habe vor einige Tage aber irgendwo gelesen dass das auch nicht gewunscht sei. Fast genau: Ich aber statt ref:myproject=(foreign key) lieber schreiben ref:myproject=(unser_projekt_OSM_ID). Der Unterschied ist minim, denn ich will der OSM nicht meine Objekt unterjubeln, sondern das OSM Objekt in unserer externen DB verwenden und den Mappern gleichzeitig signalisieren, dass es dieses externe Projekt gibt. Das ist ja nun auch großer Käse...wie viel Anwendungen gibt es, die mit OSM-Daten arbeiten...Wo soll das enden, wenn jede Anwendung irgendwelche spezifischen Tags an Objekte hängt? Also nochmals um das klarzustellen: Anwendungen, die mit der OSM ID wie sie jetzt ist klarkommen, brauchen nichts zu tun. Anwendungen hingegen, die OSM nicht mit eigenen Daten belasten und z.B. selber weitere Attribute verwalten wollen, sind auf (für sie) permanente/stabile/dauerhafte OSM IDs angewiesen. Dazu dient dieser Vorschlag. Und was bringt es, wenn jemand das Objekt mit samt dem raf-Tag löscht und ein neues ohne all die ref-Tags erstellt? Das würde in meinem Fall ein Achtung da hat jemand unser Objekt gelöscht signalisieren und er müsste dem nachgehen, was Sache ist. Jedenfalls hoffe ich nicht, dass es unlautere Absichten sind, denn bestehende Tags sollten ja erhalten bleiben, wenn das Objekt z.B. nur verschoben wird (vgl. das DIDOK-Beispiel oben). 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. LG, S. Am 22. Juli 2012 22:14 schrieb aighes o...@aighes.de: Am 22.07.2012 21:38, schrieb Jo: Ich würde auch ein Tag wie ref:myproject=(foreign key) benutzen. Ich habe vor einige Tage aber irgendwo gelesen dass das auch nicht gewunscht sei. Das ist ja nun auch großer Käse...wie viel Anwendungen gibt es, die mit OSM-Daten arbeiten...Wo soll das enden, wenn jede Anwendung irgendwelche spezifischen Tags an Objekte hängt? Und was bringt es, wenn jemand das Objekt mit samt dem raf-Tag löscht und ein neues ohne all die ref-Tags erstellt? 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. 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] Permanente/stabile OSM IDs!
Am 22.07.2012 21:22, schrieb Stefan Keller: Wenn ich mir diese Beispiele anschaue - und annehme, dass Tools (wie JOSM) korrekt arbeiten und richtig angewendet werden -, dann sehe ich keinen Anlass, die OSM ID's grundsätzlich als instabil zu bezeichnen. Ich lasse mich aber gern - bzw. weils's sein muss :- vom Gegenteil überzeugen. Viele Bearbeitungsoperationen kann man in der Tat so durchführen, dass eine ID erhalten bleibt, aber das ist keine Garantie, dass ein Mapper auch diesen Weg wählen wird - und es gibt auch keine Pflicht, das zu tun. Zudem gibt es Änderungen der Darstellungsform (Umbau von Node auf Fläche, oder von geschlossenem Way auf Relation), bei denen der Erhalt einer ID schon vom Prinzip her nicht möglich ist. Ebensowenig kann etwa beim Auftrennen eines der Ways einer Straße die Liste der IDs für die Straße erhalten bleiben. 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. Es ändert schon etwas: IDs sind versteckte Eigenschaften, die der Mapper bedenkenlos ändern darf und oft wird. Tags sind hingegen Eigenschaften, bei denen beim Bearbeiten klar sein sollte, dass das nach außen, also für Datennutzer, Folgen haben wird und man sich daher beim Ändern Gedanken machen muss. Mein Minimalvorschlag ist, dass nur eine klar am Tagnamen erkennbare projektspezifische ID eingeführt wird, die niemals mehr verändert wird (ausser sie geht mit dem OSM Objekt unter). Die externe Datenbank verwaltet die Beziehung zwischen ihren Objekten und dem so bezeichneten OSM-Objekt selber. Bei OpenMetaMap steht zurzeit OSM ID (für keyA bzw. Object ID); da wäre nun nur noch eine openmetamap_osm_id nötig. Diese Option scheitert schon daran, dass es auf lange Sicht zu viele Datenbanken geben dürfte, die mit OSM interagieren wollen. Das geht gut, solange es sich um einige wenige, bekannte Projekte handelt - z.B. bei den existierenden Wikipedia-Links -, aber wenn jetzt außer Flickr noch dutzende weitere kommerzielle Fotoportale OSM-Verlinkungen einführen wollen, würden diese Tags ausufern. Es ist außerdem auch nicht klar, welche Eigenschaft dem Verlinker nun wichtig ist. Wenn ein Restaurant umzieht, ist es dann noch dasselbe Restaurant? Die Definition von dasselbe ist vermutlich für jedes der verlinkten Projekte anders, und man kann nicht erwarten, dass der Mapper die Kriterien jedes der Projekte kennt. Bei einer Query hingegen ist das ganz automatisch definiert - da müssen in der Query eben genau die Eigenschaften eingebaut sein, die für den Verlinker das Objekt ausmachen. Von daher denke ich weiterhin, dass die Identifikation über Eigenschaften aus der realen Welt (was auf geeignete Queries in z.B. Overpass hinausläuft) die richtige Lösung ist. Solche Probleme wie dein Beispiel mit Leerzeichen sind vorhersehbar, so dass man sich in vielen Fällen darauf vorab einstellen kann. Gruß, Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Schwierig, zumal bei Übetragungen von Node auf Way sich die eigentliche OSM-ID schon ändert. Was am meisten bestand hat, sind IDs aus offiziellen Katalogen. Diese sind dann aber Attributabhängig. Sprich: Es gibt m.W.n. IDs für Schulen in Hessen, die jetzt kräftig eingepflegt wurden. Es gibt auch für jede Straße eine offizielle ID (die man z.B. bei der Fahrrad-Kodierung verwendet) oder halt auch für jede Ortschaft. Das bedeutet aber, dass man da erstmal einen externen Katalog finden muss. Natürlich ginge es auch eine ID aus einem eigenen Katalog zu verpassen, um es mit dem eigenen Projekt zu verknüpfen, jedoch bevorzuge ich schon offizielle Identifikationsmerkmale, und nicht zig ref:*=* zu ein und dem selben Objekt Der Übersichtlichkeit wegen ;). MfG Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Hallo Simon 2012/7/22 Simon Poole si...@poole.ch: Nur mal zum über den Hag schauen: http://en.wikipedia.org/wiki/TOID Das wäre genau so eine Projekt ID, die ich meinte! Stefan 2012/7/22 Simon Poole si...@poole.ch: Nur mal zum über den Hag schauen: http://en.wikipedia.org/wiki/TOID Am 22.07.2012 22:19, schrieb Walter Nordmann: schau dir mal die sache mit den uuids an. ich glaube, dass das ein interessanter Ansatz ist. https://wiki.openstreetmap.org/wiki/Proposed_Features/UUID von diesem thread find ich gerade nicht den anfang: http://www.mail-archive.com/talk@openstreetmap.org/msg30181.html uuid für osm geistert schon lange bei uns rum, ist aber irgendwie eingeschlafen. Gruss walter p.s. sorry, bin gerade knapp dran mit zeit. -- View this message in context: http://gis.19327.n5.nabble.com/Permanente-stabile-OSM-IDs-tp5717856p5717870.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 ___ 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] Permanente/stabile OSM IDs!
Hallo Peter Am 22. Juli 2012 22:30 schrieb Peter Wendorff wendo...@uni-paderborn.de: ... Nehmen wir an, ich trage einen Supermarkt als Node ein - ein gängiger Weg, wenn ich keine Luftbilder zur Verfügung habe. Beim Hochladen bekommt dieser Supermarkt die Id node 42 - denn osm hat ja für nodes, ways und relations getrennte id-räume. Jetzt kommst du und hast 'n Luftbild, willst den supermarkt also besser eintragen als Polygon: Das ist ein interessanter Fall, der mir auch von (Einzel-)Parkplätzen und (Einzel-)Bäumen etc. bekannt ist. 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. LG, Stefan Am 22. Juli 2012 22:30 schrieb Peter Wendorff wendo...@uni-paderborn.de: Hallo Stefan. Ich glaube, du hast dir da direkt ein schwierigeres Thema rausgesucht - und ich hab dazu sicher auch keine perfekte Lösung. Den Ansatz der Overpass-API hast du ja schon mit aufgelistet, und ich halte ihn für momentan den am ehesten praxistauglichen. Deine anderen Ideen kritisiere (bitte nicht übelnehmen) ich mal zwischen deinem Text: Am 22.07.2012 21:22, schrieb Stefan Keller: 1. Sind OSM ID's wirklich instabil? bzw. Wann ändern IDs ungewollt/unfreiwillig? Nehmen wir an, ich trage einen Supermarkt als Node ein - ein gängiger Weg, wenn ich keine Luftbilder zur Verfügung habe. Beim Hochladen bekommt dieser Supermarkt die Id node 42 - denn osm hat ja für nodes, ways und relations getrennte id-räume. Jetzt kommst du und hast 'n Luftbild, willst den supermarkt also besser eintragen als Polygon: Wenn/da du weißt, dass ids zum verlinken genutzt werden könnten, benutzt du den alten node als startknoten des gebäudepolygons und kopierst die daten auf das polygon. Der way hat jetzt eine ID way23 - und die id node42 kann er auch gar nicht kriegen, das hat mit dem editor nichts zu tun. Wenn eine Software aber zur ID node42 verlinkt, wird er z.B. die Öffnungszeiten nicht mehr finden können, denn die hängen jetzt korrekterweise am way23. Eine Korrektur hin zu stabilen ObjektIDs ist also mit der aktuellen API nicht machbar - und vermutlich auch so ohne weiteres dauerhaft nicht zu lösen, denn: - Ich trage das Gebäude Mozartstraße 3 als Polygon way323 ein mit building=yes, amenity=doctors. - Eine Datenbank D verlinkt das Gebäude (way323), um die Arztpraxis von Dr. OSM zu markieren. - Du verbesserst OSM und trägst die drei Arztpraxen von Dr. OSM, Dr. Etsch und Dr. doofe-IDee als einzelne nodes ein. Auf einmal ist zwar das ursprüngliche polygon noch da, aber das ist gar nicht das, was die externe datenbank meinte - die verlinkt immer noch zum damals am besten passenden Objekt. Das war zwar vorher schon eine Arztpraxis, aber eben noch ungenau, die drei arztpraxen wurden als eine abgebildet. 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 stimmt nicht, wenn du den node nur verschiebst. Dafür musst du ihn kopieren und einfügen. Das ist aber kein logisch zwingender Grund, sondern technischer Mangel. Nein. Nur eine andere Interpretation dessen, was richtig ist, als du sie annimmst. Wenn nur die Way Tags ändern, dann sind sich hoffentlich alle einig, dass deswegen keine neue Way ID erzeugt wird. Wird ein Way geometrisch verlängert oder ein Node eingefügt, dann hoffentlich auch nicht! Im Sinne stabiler IDs: Wenn ein way das Tag highway=residential verliert und jetzt auf einmal stattdessen building=yes bekommt, dann ist das ein neues Objekt. Wenn dagegen highway=residential durch highway=pedestrian ausgetauscht wird, ist die Straße im Grunde die gleiche geblieben. 2. OSM ID's sind grundsätzlich stabil! Wenn ich mir diese Beispiele anschaue - und annehme, dass Tools (wie JOSM) korrekt arbeiten und richtig angewendet werden -, dann sehe ich keinen Anlass, die OSM ID's grundsätzlich als instabil zu bezeichnen. Ich lasse mich aber gern - bzw. weils's sein muss :- vom Gegenteil überzeugen. Guck dir alle Städte an, die bisher noch Hausnummern in Form von Nodes enthalten, verschaff denen aktive Mapper mit etwas Langeweile und gute Luftbilder - und schon sind deine alten Nodes weg und unter neuen IDs die gleichen Hausnummern in Form von Gebäudepolygonen drin - tausendfach. 3. Projekt-ID Tag als Lösung? 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
Re: [Talk-de] Permanente/stabile OSM IDs!
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 Link in dieser Datenbank anlegen lassen und den dann ueberall benutzen. 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? Es waere trivial, in dieser Datenbank eine Liste zu generieren mit allen kaputten Links; es waere sogar moeglich, diese nach Nutzungsintensitaet zu sortieren, so dass viel genutzte Links von Freiwilligen sofort repariert werden koennen, wenn sie kaputt gehen. Es waere sogar denkbar, in dieser Datenbank das letzte bekannte gute Ergebnis aus OSM zu cachen fuer jeden Link, so dass man, selbst wenn bei OSM was kaputt geht, dem Anfrager immer noch wenigstens eine alte Version ausliefern kann. Und das beste: Man muss OSM nicht mit seinen Privatkeys ueberfluten, um das machen zu 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] Permanente/stabile OSM IDs!
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. 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. Sinnvoller wäre es, bspw. über die OverpassAPI nach einem Restaurant mit dem Namen xyz in der BBox... zu fragen. 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). In beiden Fällen kommt bei dem Projekt Unsinn an, der evtl. nicht bemerkt wird und wenn er bemerkt werden würde, dann würde er auch bemerkt, wenn man nach der OSM-ID gegangen wäre. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Hoi Andreas Am 22. Juli 2012 22:52 schrieb Andreas Neumann andr-neum...@gmx.net: Schwierig, zumal bei Übetragungen von Node auf Way sich die eigentliche OSM-ID schon ändert. Genau. Siehe auch meine Antwort an Peter oben. Was am meisten bestand hat, sind IDs aus offiziellen Katalogen. Diese sind dann aber Attributabhängig. Sprich: Es gibt m.W.n. IDs für Schulen in Hessen, die jetzt kräftig eingepflegt wurden. Solch ein offizieller Katalog wären genau solch ein Projekt einer externen Datenbank. Meine Idee ist es nun aber, dass dieser Katalog weiterhin bestehen bleibt und nicht meint, er könne OSM mit einem Import beglücken und durch OSM ersetzt zu werden. Mein Vorschlag zielt darauf ab, dass diese Schulhäuser in OSM getaggt und wenn nötig/möglich eingetragen werden (sagen wir als Gebäudepolygone), OSM dann aber auch genutzt werden kann, um den Katalog aktuell zu halten. LG, Stefan Am 22. Juli 2012 22:52 schrieb Andreas Neumann andr-neum...@gmx.net: Schwierig, zumal bei Übetragungen von Node auf Way sich die eigentliche OSM-ID schon ändert. Was am meisten bestand hat, sind IDs aus offiziellen Katalogen. Diese sind dann aber Attributabhängig. Sprich: Es gibt m.W.n. IDs für Schulen in Hessen, die jetzt kräftig eingepflegt wurden. Es gibt auch für jede Straße eine offizielle ID (die man z.B. bei der Fahrrad-Kodierung verwendet) oder halt auch für jede Ortschaft. Das bedeutet aber, dass man da erstmal einen externen Katalog finden muss. Natürlich ginge es auch eine ID aus einem eigenen Katalog zu verpassen, um es mit dem eigenen Projekt zu verknüpfen, jedoch bevorzuge ich schon offizielle Identifikationsmerkmale, und nicht zig ref:*=* zu ein und dem selben Objekt Der Übersichtlichkeit wegen ;). MfG Andreas ___ 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] Permanente/stabile OSM IDs!
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 :- 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. 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. 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. LG, Stefan 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. 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. Sinnvoller wäre es, bspw. über die OverpassAPI nach einem Restaurant mit dem Namen xyz in der BBox... zu fragen. 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). In beiden Fällen kommt bei dem Projekt Unsinn an, der evtl. nicht bemerkt wird und wenn er bemerkt werden würde, dann würde er auch bemerkt, wenn man nach der OSM-ID gegangen wäre. 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] Permanente/stabile OSM IDs!
Hallo, Am 22. Juli 2012 22:58 schrieb Frederik Ramm frede...@remote.org: 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. Kann ich mit Leben ink. allen erwähnten hypothetischen Fällen. Daher ja mein Vorschlag von Projekt/privaten IDs :- 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. 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. 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. Das Verschieben soll aber auch funktionieren, wenn es um Parkbänke geht, die keinen Namen haben! UUID ist ein Spezialfall von meinem Vorschlag einer Projekt-ID. Im Gegensatz zu UUIDs verlangen meine Projekt-IDs aber nicht, dass sich alle an eine gemeinsame UUID-Spezifikation halten, sondern lediglich, dass der Mapper den Tag in Ruhe lässt. Wenn dann noch die Editoren den Mapper beim Verschieben besser unterstützen (und wirklich updaten und nicht löschen und neu erzeugen), dann umso besser für OSM - und die Projekt-Datenbank. ... 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. Wie gesagt, ist damit der (häufige) Fall nicht abgedeckt, für alle diese Objekte, für die die Mapper keine ref-Links (o.ä.) ausdenken. 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. Sehe keinen Unterschied zu meinem Vorschlag, denn auch hier werden Links als Tags ins OSM Objekt gesetzt. Ich könnte mir höchstens vorstellen, dass mein Vorschlag nur dort zum Zuge kommt, wo Mapper keine Links setzen. Was aber eine gute Idee waere: Vorab: Genau diese Idee steckt hinter meinem Vorschlag. Der Vorteil meines Vorschlags ist, dass es das Overpass-Permanent-ID-Konzept ergänzt (und ursprünglich auf ein Tag einschränken wollte), da das Overpass-Permanent-ID-Konzept nur für OSM Objekte funktioniert, die für Mapper einen sprechenden Schlüssel haben. 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. Soweit wie gesagt einverstanden. 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). Deine Hinweise oben drängen für mich eine Kombination des Overpass-Permanent-ID-Konzept mit meinem Vorschlag auf: Projekt-IDs würden dann nur vergeben, wenn in der OSM DB keine zusammengesetzte Schlüssel vergeben werden können, wie das wohl z.B. bei Sitzbänken, Briefkästen, etc. der Fall ist. Jeder kann bei Bedarf einen Link in dieser Datenbank anlegen lassen und den dann ueberall benutzen. 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? Es
Re: [Talk-de] Permanente/stabile OSM IDs!
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 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? Das Verschieben soll aber auch funktionieren, wenn es um Parkbänke geht, die keinen Namen haben! 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. 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!) - 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!) 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? Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [osm-ve] Mapa Borrado IMPORTANTE!
2012/7/22 hyan...@gmail.com hyan...@gmail.com Excelente! Hernán. Si es de su deseo incrementar la densidad en los datos, WalkingPapers es una buena opción para ello. A que te refieres?? El día 22 de julio de 2012 08:06, J. Hernán Ramírez R. hernan.rami...@gmail.com escribió: hyances: Ya recuperé la data de la zona!! -- 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 hyan...@gmail.com hyan...@gmail.com La eliminación es por cambio de licencia, alguno de los datos en La Victoria [1] los tiene el usuario [2] de la Fundación OSM para la redacción de la nueva licencia. Hay algunas trazas GPX disponibles para calcar, unas cuantas aun no tienen vectores sobre ella. Si hay maperos en el área podemos reconstruir la data con GPS y WalkingPapers [3] Saludos, Humberto Yances [1] http://www.openstreetmap.org/?lat=10.2294lon=-67.3169zoom=14layers=M [2] http://www.openstreetmap.org/user/OSMF%20Redaction%20Account [3] http://walkingpapers.org/ l 22 de julio de 2012 07:44, J. Hernán Ramírez R. hernan.rami...@gmail.com escribió: Recuerdo que esa zona se calqueó desde las imágenes de Yahoo, que hoy día no están disponibles... Me huele a sabotaje pues las huellas en el mapa son muy extrañas... Listo data recuperada en un 90% 8000 puntos recuperados!!! http://www.openstreetmap.org/user/hernanr/edits Faltan algunos POIs y hacer ajustes en continuidad de vías Antes Ahora Favor dar una mirada en general a el Mapa de Venezuela... de conseguir problemas anunciarlos a la lista.. -- 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. Hernán Ramírez R. hernan.rami...@gmail.com Ya empece a recuperar la data borrada... -- 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/21 hyan...@gmail.com hyan...@gmail.com Al cargar nuevamente la base de datos, el usuario usará OdBL como licencia para los datos. Sobre reversiones en los conjuntos de cambios: http://help.openstreetmap.org/questions/731/how-can-i-revert-a-changeset Plugin JOSM: http://wiki.openstreetmap.org/wiki/JOSM/Plugins/Reverter Scripts de reversiones: http://wiki.openstreetmap.org/wiki/Revert_scripts Esto hay que hacerlo con cuidado. El día 21 de julio de 2012 22:05, J. Hernán Ramírez R. hernan.rami...@gmail.com escribió: En Mérida todo parece normal.. no he visto nada eliminado... tengo algunos resplado del mapa de venezuela.. de finales de diciembre... voy a revisar a ver si encuentro algo que recuperar.. -- 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/21 J. Hernán Ramírez R. hernan.rami...@gmail.com Por fa envíame el link de la zona para revisar y detectar que ocurrió El 21/07/2012 13:24, J. Rojas rojas...@gmail.com escribió: lamentable de verdad que se haya perdido información con la que ya contábamos (sobretodo esta zona estaba muy bien mapeada y dedicar nuevamente horas de trabajo a una zona donde ya se habia realizado), estuve chequeando con Potlach los nuevas imágenes de la cobertura de bing y desafortunadamente esta zona no se encuentra para nada con detalle, me dedicare en la medida de lo posible captar trazas para reconstruir esta zona. ¿alguien mas a observado que se ha perdido data en otra zona del pais? El 21 de julio de 2012 12:10, hyan...@gmail.com hyan...@gmail.com escribió: Esto puede obedecer al cambio de la licencia hacia Odbl [1][2], se han eliminado los datos de los usuarios que no lo aceptaron. Por lo tanto hay que reconstruir esas
Re: [osm-ve] Mapa Borrado IMPORTANTE!
Gracias Hernan por recuperar la data. Estuve desconectado y ocupado unas horas, pero para alegría veo que ya nos ayudaste con la mayoria de la data. Sin embargo observe que faltan algunos detalles que yo me ocupare de ello gracias a que soy de la zona. NOTA: encontre algo raro en este usuario s-o-fhttp://www.openstreetmap.org/user/s-o-fcomo hacemos para saber si es el que esta saboteando OSM? El 22 de julio de 2012 08:36, J. Hernán Ramírez R. hernan.rami...@gmail.com escribió: hyances: Ya recuperé la data de la zona!! -- Salva un árbol. No imprimas este correo a menos que sea realmente necesario. - J. Hernán Ramírez R Blog http://blog.hernanramirez.info - Linux User #97.898http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=97898 - Twitter @HernanRamriez http://twitter.com/HernanRamirez Mapas Libres OpenStreetmap Venezuela http://openstreetmap.org.ve - 2012/7/22 hyan...@gmail.com hyan...@gmail.com La eliminación es por cambio de licencia, alguno de los datos en La Victoria [1] los tiene el usuario [2] de la Fundación OSM para la redacción de la nueva licencia. Hay algunas trazas GPX disponibles para calcar, unas cuantas aun no tienen vectores sobre ella. Si hay maperos en el área podemos reconstruir la data con GPS y WalkingPapers [3] Saludos, Humberto Yances [1] http://www.openstreetmap.org/?lat=10.2294lon=-67.3169zoom=14layers=M [2] http://www.openstreetmap.org/user/OSMF%20Redaction%20Account [3] http://walkingpapers.org/ l 22 de julio de 2012 07:44, J. Hernán Ramírez R. hernan.rami...@gmail.com escribió: Recuerdo que esa zona se calqueó desde las imágenes de Yahoo, que hoy día no están disponibles... Me huele a sabotaje pues las huellas en el mapa son muy extrañas... Listo data recuperada en un 90% 8000 puntos recuperados!!! http://www.openstreetmap.org/user/hernanr/edits Faltan algunos POIs y hacer ajustes en continuidad de vías Antes Ahora Favor dar una mirada en general a el Mapa de Venezuela... de conseguir problemas anunciarlos a la lista.. -- Salva un árbol. No imprimas este correo a menos que sea realmente necesario. - J. Hernán Ramírez R Blog http://blog.hernanramirez.info - Linux User #97.898http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=97898 - Twitter @HernanRamriez http://twitter.com/HernanRamirez Mapas Libres OpenStreetmap Venezuela http://openstreetmap.org.ve - 2012/7/22 J. Hernán Ramírez R. hernan.rami...@gmail.com Ya empece a recuperar la data borrada... -- Salva un árbol. No imprimas este correo a menos que sea realmente necesario. - J. Hernán Ramírez R Blog http://blog.hernanramirez.info - Linux User #97.898http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=97898 - Twitter @HernanRamriez http://twitter.com/HernanRamirez Mapas Libres OpenStreetmap Venezuela http://openstreetmap.org.ve - 2012/7/21 hyan...@gmail.com hyan...@gmail.com Al cargar nuevamente la base de datos, el usuario usará OdBL como licencia para los datos. Sobre reversiones en los conjuntos de cambios: http://help.openstreetmap.org/questions/731/how-can-i-revert-a-changeset Plugin JOSM: http://wiki.openstreetmap.org/wiki/JOSM/Plugins/Reverter Scripts de reversiones: http://wiki.openstreetmap.org/wiki/Revert_scripts Esto hay que hacerlo con cuidado. El día 21 de julio de 2012 22:05, J. Hernán Ramírez R. hernan.rami...@gmail.com escribió: En Mérida todo parece normal.. no he visto nada eliminado... tengo algunos resplado del mapa de venezuela.. de finales de diciembre... voy a revisar a ver si encuentro algo que recuperar.. -- 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/21 J. Hernán Ramírez R. hernan.rami...@gmail.com Por fa envíame el link de la zona para revisar y detectar que ocurrió El 21/07/2012 13:24, J. Rojas rojas...@gmail.com escribió: lamentable de verdad que se haya perdido información con la que ya contábamos (sobretodo esta zona estaba muy bien mapeada y dedicar nuevamente horas de trabajo a una zona donde ya se habia realizado), estuve chequeando con Potlach los nuevas imágenes de la
[osm-ve] Maracay Mapa Borrado
Ok fijandome en otra zona tenemos el mismo inconveniente que con La Victoria, en este caso les dejo el Link Maracayhttp://c.tile.openstreetmap.org/15/10231/15446.pngpara 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
Re: [osm-ve] Maracay Mapa Borrado
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
Re: [Talk-in] Data loss due to license change
On Sun, Jul 22, 2012 at 11:09 AM, Sajjad Anwar sajja...@gmail.com wrote: OSM Inspector should be handy http://tools.geofabrik.de/osmi/debug.html?view=botlon=77.82860lat=10.79962zoom=8overlays=overview,bot_point_modified,bot_line_modified_cp,bot_line_modified,bot_point_deleted,bot_line_deleted_cp,bot_line_deleted It does not give information about its creator. How we can find that? Can we have information, similar to at: http://odbl.de/india.html state wise or city wise? -- H.S.Rai ___ 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, 2012-07-22 at 10:49 +0530, Arun Ganesh wrote: I think the osm redaction bot has finished cleaning up India and removed all non-odbl data. and thankfully all my stuff remains. -- regards Kenneth Gonsalves ___ Talk-in mailing list Talk-in@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-in
Re: [Talk-it] Statistiche GFOSS (strade perse)
On Thu, Jul 19, 2012 at 04:49:56PM +0200, Diego Guidotti - Aedit s.r.l. wrote: Ho fatto rigirare le statistiche sul sito GFOSS [1] per verificare le perdite a seguito della pulizia della banca dati dei dati incompatibili con la nuova licenza. L'azione del bot è terminata? Siamo sicuri che possiamo iniziare a sistemare i danni senza ulteriori sorprese? -- Niccolo Rigacci - http://www.rigacci.net/ Firenze - Italy Tel. ufficio: 055-9331021 ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] distanze città italiane
Il 07/22/2012 11:59 AM, sabas88 scrisse: Ho fatto una prova su Genova-Milano. C'è una differenza di georeferenziazione fra OSM e Google, ad esempio a Milano le coordinate su OSM danno il viottolo dietro il Museo del 900 (sud di piazza duomo) mentre su Google danno Via Foscolo (nord di piazza duomo). Usano due proiezioni diverse? La differenza genera due percorsi totalmente diversi all'interno di Milano, una volta aggiustato a mano sono più simili. L'avevo notato anch'io. Probabilmente la differenza risiede nel fatto che nominatim e google restituiscono due punti diversi per il centro citta'. Anche la differenza dei tempi di percorrenza milano-roma e' abbastanza preoccupante. Anche se c'e' da dire che google calcola i tempi in base all'orario (e al traffico?). ciao maxx ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] distanze città italiane
Si, è utile. Puoi aggiungere Vicenza? Grazie. Luca Il giorno 22/lug/2012 11:41, Simone Cortesi sim...@cortesi.com ha scritto: Ciao, grazie all'aiuto di Kai Krueger, ho appena generato questa tabella http://maps.cortesi.com/distanze_italia.html ho effettuato un confronto in automatico fra la distanza in macchina riportata da OSRM e Google. Dovrebbe segnalare in rosso le anomalie 5% e contiene le citta' italiane sopra i 200.000 abitanti (cioe' le prime 15 per popolazione - secondo wikipedia). Alcuni casi sono falsi positivi. ditemi se vi è utile, che posso espanderlo a comprendere un maggior numero di città e generarlo frequentemente. -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Quattro mesi di OSM su Foursquare
Il 21/07/2012 22:59, sabas88 ha scritto: Ciao, vi segnalo questo post pubblicato da Mapbox e Foursquare sulla loro interazione con OSM e gli utenti. http://blog.foursquare.com/2012/07/10/making-a-better-map-four-months-of-openstreetmap-with-mapbox-foursquare/ Alla fine si sono dati da fare! Stefano Interessante. Bello anche il commento: So when is Foursquare going to start contributing it's *venue* data back to the OpenStreetMap project? ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] distanze città italiane
Si, il servizio è molto utile. Ho già corretto un tratto di autostrada (tragitto Roma-Milano) che era stato cancellato. Grazie! -- Enrico Piccinelli picc...@tiscali.it___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] distanze città italiane
Se è possibile, per controllare la Sardegna inserirei Olbia, Cagliari e Sassari (o Porto Torres) che sono sulle direttrici principali. Un altro miglioramento che farei sarebbe inserire due gradazioni di colore, tipo giallo per il 5% e rosso per il 10%, finchè sono 5 chilometri ancora è accettabile IMHO. Stefano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] distanze città italiane
Ben vengano degli strumenti per verifiche di ogni tipo. Riguardo al confronto in oggetto vedo che tiene conto dei tempi e non delle distanze, parametro soggettivo per ogni motore di routing; personalmente mi preoccuperei delle differenze sulle distanze. Verificando su Genova le due discrepanze più eclatanti (Genova - Roma 25km e Genova - Palermo 300km) si vede che nel primo caso OSM percorre la litoranea mentre G fa tutto in autostrada, nel secondo caso G a Salerno fa prendere il traghetto. Alessandro ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] distanze città italiane
Il giorno 22 luglio 2012 13:29, ale_z...@libero.it ale_z...@libero.it ha scritto: Ben vengano degli strumenti per verifiche di ogni tipo. Riguardo al confronto in oggetto vedo che tiene conto dei tempi e non delle distanze, parametro soggettivo per ogni motore di routing; personalmente mi preoccuperei delle differenze sulle distanze. Verificando su Genova le due discrepanze più eclatanti (Genova - Roma 25km e Genova - Palermo 300km) si vede che nel primo caso OSM percorre la litoranea mentre G fa tutto in autostrada, nel secondo caso G a Salerno fa prendere il traghetto. OSRM sui traghetti ancora perde un po', perchè si incarta sull'accesso al porto (probabilmente i cancelli che mettiamo non vanno bene, infatti partendo da dentro il porto funzionano)... Altra cosa, tutti i calcoli da Firenze hanno fallito perchè Piazza della Repubblica è pedestrian, cambierei le coordinate in 43.771389,11.254167. Da quanto leggo qui (http://en.wikipedia.org/wiki/Google_Maps#Map_projection) Gmaps usa il WGS84. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] distanze città italiane
ok, ho aggiunto alla mia lista Vicenza, Olbia, Cagliari e Sassari. domani pomeriggio la genero nuovamente e mando mail in lista. se ci sono altre citta' da aggiungere, fatevi avanti. -S 2012/7/22 luca menini menini.l...@gmail.com: Si, è utile. Puoi aggiungere Vicenza? Grazie. Luca Il giorno 22/lug/2012 11:41, Simone Cortesi sim...@cortesi.com ha scritto: Ciao, grazie all'aiuto di Kai Krueger, ho appena generato questa tabella http://maps.cortesi.com/distanze_italia.html ho effettuato un confronto in automatico fra la distanza in macchina riportata da OSRM e Google. Dovrebbe segnalare in rosso le anomalie 5% e contiene le citta' italiane sopra i 200.000 abitanti (cioe' le prime 15 per popolazione - secondo wikipedia). Alcuni casi sono falsi positivi. ditemi se vi è utile, che posso espanderlo a comprendere un maggior numero di città e generarlo frequentemente. -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] distanze città italiane
In data domenica 22 luglio 2012 14:06:02, Simone Cortesi ha scritto: se ci sono altre citta' da aggiungere, fatevi avanti. Bolzano! ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] distanze città italiane
Il giorno 22 luglio 2012 15:21, Alessio Zanol nar...@infinito.it ha scritto: In data domenica 22 luglio 2012 14:06:02, Simone Cortesi ha scritto: se ci sono altre citta' da aggiungere, fatevi avanti. Bolzano! Per favore: Lecce Grazie, Berti ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Boundaries
On 07/22/2012 06:36 PM, Matteo Gottardi wrote: http://www3.istat.it/ambiente/cartografia/versione_non_generalizzata.html ), iniziando dal Südtirol - Alto Adige, dove mancano parecchi comuni. Mi sai dire quali comuni altoatesini mancano? Non ho accesso a un shape-file, ma un server WMS della provincia con le confini comunali (e partemente anche le confini dei frazioni (se sono stati comuni autonomi prima del 1927), e le ho solo aggiustate per le comuni della val pusteria e alcuni dell'alta valle d'isarco: Rio Pusteria, Vandoies, Chienes, Rodengo, San Lorenzo di Sebato, Falzes, Naz-Sciaves, Varna, Fortezza, Gais, Marebbe, Valdaora, Villabassa, Monguelfo-Tesido, Valle di Casies, San Candido, Sesto, Dobbiaco, Rasun-Anterselva, Perca, Braies. -- Cheers, Alex ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] distanze città italiane
On 22/07/2012 14:06, Simone Cortesi wrote: se ci sono altre citta' da aggiungere, fatevi avanti. Magari Sondrio e Aosta? Grazie! Carlo -- .' `. | Registered Linux User #443882 |a_a | | http://counter.li.org/ .''`. \_)__/ +--- : :' : /( )\ ---+ `. `'` |\`/\ Registered Debian User #9 | `- \_|=='|_/ http://debiancounter.altervista.org/ | ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] distanze città italiane
On 22/07/2012 13:51, sabas88 wrote: OSRM sui traghetti ancora perde un po', perchè si incarta sull'accesso al porto (probabilmente i cancelli che mettiamo non vanno bene, infatti partendo da dentro il porto funzionano)... 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.110190loc=42.413699,12.097878loc=42.416420,12.097330z=16center=42.415164,12.099552df=0 (probabilmente barrier=sally_port viene ignorato) Questa la sua risposta: will be fixed when the new road network extraction comes to life Non mi ha saputo però dare una stima dei tempi. Ciao! Carlo -- .' `. | Registered Linux User #443882 |a_a | | http://counter.li.org/ .''`. \_)__/ +--- : :' : /( )\ ---+ `. `'` |\`/\ Registered Debian User #9 | `- \_|=='|_/ http://debiancounter.altervista.org/ | ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Google si mette in proprio anche in Italia
Questa è troppo forte... Guardate in mare a Livorno... Altro che ponte sullo stretto! Si va in corsica in macchina! Il giorno domenica 22 luglio 2012, EdoardoT ha scritto: Confermo che anche a casa mia hanno modificato le strade. Mentre prima era praticamente tutto giusto con tanto di driveway, adesso ne hanno tolte un sacco e aggiunte di nuove tanto che secondo google casa mia è tagliata in due da una strada... Ma almeno loro potrebbero usare streetview?? Il giorno sabato 21 luglio 2012, Guido Piazzi ha scritto: Il 20/07/2012 11:16, totera ha scritto: Ciao a tutti, grosse novità stamattina in casa del nemico... Io avrei qualche difficoltà a chiamare nemico o anche solo concorrente uno che mi dà una mano a comprare i server... Da un rapido sguardo direi che per quanto riguarda la rete stradale le nuove mappe sono più aggiornate delle precedenti ma ho notato diversi errori nei nomi delle strade e casi di classificazione incoerente. Se volete farvi quattro risate, date un'occhiata a San Vittore Olona: http://tools.geofabrik.de/mc/?**mt0=mapnikmt1=googlemaplon=** 8.9424lat=45.58414zoom=16http://tools.geofabrik.de/mc/?mt0=mapnikmt1=googlemaplon=8.9424lat=45.58414zoom=16 Su OSM alcune vie mancano (il comune adiacente di Cerro Maggiore è conciato molto peggio) ma i nomi sono giusti, mentre Google è incredibile quanti ne sbaglia! Nel comune dove abito, mancano tutte le piazze e alcune vie hanno il nome sbagliato, ma stranamente la ricerca di questi toponimi che sembrano mancare funziona... come avranno fatto? Forse questa mossa ha qualcosa a che fare con il recente ribasso delle tariffe per l'utilizzo di Maps API per i siti ad alto traffico. Guido __**_ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-ithttp://lists.openstreetmap.org/listinfo/talk-it -- * * * Edoardo Tona* -- * * * Edoardo Tona* ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Strumenti per il remapping post-bot
Il 07/21/2012 01:48 PM, Alberto Nogaro scrisse: L'andamento della way a Milano dovrebbe essere abbastanza facile da ripristinare dalla foto aeree. Milano e' grande! Ci sono almeno 1 highway, non e' cosi' banale. Ad esempio ho gia' visto che sono spariti dei tratti di via relativamente brevi. Se non ingrandisci abbastanza la mappa e' facile che non ci si accorga di nulla. Per i dati confermati dai rilevatori, direi che puoi ripristinare la way e i tag relativi. Se la way aveva tag che i rilevatori hanno ignorato e non hai altre fonti per confermarli, non li ripristinare. Per recuperare i tag della way eliminata può essere utile http://tools.geofabrik.de/osmi/debug.html?view=bot (cliccando sull'elemento eliminato ti mostra i tag che aveva, il servizio èancora sperimentale). Ok, molto utile. Ho notato che un problema molto subdolo sono i nodi rimasti orfani. ne ho gia' trovato qualcuno. Mi pareva di aver letto qualcosa in proposito ma non trovo piu' il thread. E' possibile in josm trovare nodi che non facciano parte di alcuna way e non siano poi? Basta il tool di verifica? grazie maxx ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Strumenti per il remapping post-bot
Il 07/21/2012 01:48 PM, Alberto Nogaro scrisse: L'andamento della way a Milano dovrebbe essere abbastanza facile da ripristinare dalla foto aeree. Per i dati confermati dai rilevatori, direi che puoi ripristinare la way e i tag relativi. Ho trovato alcune vie a cui avevo fatto io le ultime modifiche e che sono state cancellate. Io avevo aggiunto un tag non standard. In base a quale criterio il bot le ha cancellate? In base a chi ha inserito/modificato per ultimo il tag highway? grazie maxx ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-co] Emergencia por hostilidades en el Norte del Cauca - Informe de situación No. 1
Sí, tienen razón --lapsus retoricus obsesivus--, es prioritario mantener la calidad en los datos. Para mejorar la retórica se puede renderizar con librerías diferentes a Mapnik que muestren claramente los contenidos con sus convenciones. El día 19 de julio de 2012 13:48, Ariel Nunez ingenieroar...@gmail.com escribió: Estoy de acuerdo con el man, digo Germán. No se puede poner el nombre de la categoría usando reglas de estilo? No se en maperitive, pero en SLD seria: sld:TextSymbolizer sld:Label ogc:PropertyNameResguardo Indígena+ name/ogc:PropertyName /sld:Label /sld:TextSymbolizer -Ariel. PD: Sin embargo, ya que botika existe, no habria problema en arreglarlo despues de la emergencia en caso de que se decida poner el largo ahora. 2012/7/19 Germán Márquez Mejía manch...@gmail.com: Siempre he sido y seré reticente frente a la inclusión de la categoría dentro del nombre, y esta no será la excepción. Sin embargo, leyendo las opiniones, dada la coyuntura y el afán de representar claramente la información, podríamos darnos esa licencia, aunque a largo plazo no sea lo más conveniente. Am Donnerstag, den 19.07.2012, 12:39 -0500 schrieb hyan...@gmail.com: Basado en el concepto de usabilidad y retórica cartográfica, me parece mejor brindarle explícitamente al usuario información de que se trata del Resguardo Indígena Quizgó; no veo redundancia, ya que uno comunica a las personas y el otro operará mejor en un escenario de interoperabilidad (consumo de datos por parte de aplicaciones de terceros). El día 19 de julio de 2012 12:29, Federico Explorador (Nevados.org) federico.explora...@nevados.org escribió: Hola: He hecho unos mapas provisionales con Maperitive, escalas 1:100.000 y 1:200.000, ver [1] Falta mapeo básico de pueblos, infraestructura y vías y completar los resguardos. @humano: he encontrado vías trazas tuyas sin etiquetear, me imagino que es trabajo en proceso y serán parte de un multipolígono para resguardo indígena? Nombres de los resguardos: sería bueno homogenizar el nombre: ponemos Resguardo indígena Quizgo o simplemente Quizgo. Me parece mejor incluir en el nombre Resguardo indígena, porque sino depende de la leyenda para saber de qué se trata. Pero también puede parecer redundante, qué opinan? Saludos, Federico [1] http://sdrv.ms/LvgTsw -Mensaje original- De: Fredy Rivera [mailto:fredyriv...@gmail.com] Enviado el: miércoles, 18 de julio de 2012 01:30 p.m. Para: OpenStreetMap Colombia Asunto: [Talk-co] Emergencia por hostilidades en el Norte del Cauca - Informe de situación No. 1 Hola En el documento que envia OCHA se puden identificar algunas necesidades donde nuestro equipo de maperos humanitario podria colaborar. salu2 -- Forwarded message -- From: Secretaria Tecnica SSH secreta...@colombiassh.org Date: 2012/7/18 Subject: Emergencia por hostilidades en el Norte del Cauca - Informe de situación No. 1 To: Sala de Situación s...@colombiassh.org PRIORIDADES / PUNTOS DESTACADOS La intensidad de las hostilidades en las últimas dos semanas, ha causado el desplazamiento masivo de cerca de 5.000 personas en cinco municipios del norte del Cauca, al menos 15 víctimas civiles y graves daños en viviendas y afectación a infraestructura. Se requieren medidas urgentes de protección de las comunidades indígenas y campesinas que se encuentran en la zona de riesgo. La emergencia ha superado las capacidades de autoridades municipales y departamentales. Las restricciones al acceso han limitado la respuesta a la emergencia. Para más información, consulte el informe en el siguiente enlace: http://www.colombiassh.org/site/IMG/pdf/OCHA_Colombia_-_Emergencia_en_Norte_ del_Cauca_-_18072012_final.pdf -- Cordialmente Secretaría Técnica SSH Tel. 6221100 Kr 13 No. 93- 12 Ofic. 402 secreta...@colombiassh.org http://www.colombiassh.org/site/ La Sala de Situación Humanitaria (SSH) es un esfuerzo interorganizacional para organizar información sobre necesidades de y respuestas a situaciones humanitarias. The Humanitarian Situation Room is a inter-organizational effort to organize information on needs and responses to humanitarian situations. Si no quisiera recibir esta información, por favor responda a este correo con el tema 'desuscribir'. Si quisiera ser agregado a la lista de distribución, por favor responda a este correo con el sujeto 'suscribir'. If you do not want to receive this information, please reply to this email writing 'unsubscribe' in the subject field. If you want to be added to the mailing list, please reply to this email writing 'subscribe' in the subject field. -- Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx, .ppt, .pptx, .mdb, mdbx OpenOffice es libre: se puede copiar, modificar y
Re: [Talk-co] Emergencia por hostilidades en el Norte del Cauca - Informe de situación No. 1
No tienen que ser diferentes a Mapnik. Mapnik es increíblemente flexible. Por ejemplo, el estilo en el que estoy trabajando renderiza xxx:es y además agrega alt_name entre paréntesis al final, v.gr. Avenida Contador (Calle 134). Y esto del prefijo también se puede hacer. De hecho, lo voy a agregar al estilo en el que estoy trabajando, además de la posibilidad de mostrar el nombre, tanto en lengua nativa (name), como en español (name:es). Así que ¡no temáis! Que lo que haya que mostrar lo mostramos :D Am Sonntag, den 22.07.2012, 12:03 -0500 schrieb hyan...@gmail.com: Sí, tienen razón --lapsus retoricus obsesivus--, es prioritario mantener la calidad en los datos. Para mejorar la retórica se puede renderizar con librerías diferentes a Mapnik que muestren claramente los contenidos con sus convenciones. El día 19 de julio de 2012 13:48, Ariel Nunez ingenieroar...@gmail.com escribió: Estoy de acuerdo con el man, digo Germán. No se puede poner el nombre de la categoría usando reglas de estilo? No se en maperitive, pero en SLD seria: sld:TextSymbolizer sld:Label ogc:PropertyNameResguardo Indígena+ name/ogc:PropertyName /sld:Label /sld:TextSymbolizer -Ariel. PD: Sin embargo, ya que botika existe, no habria problema en arreglarlo despues de la emergencia en caso de que se decida poner el largo ahora. 2012/7/19 Germán Márquez Mejía manch...@gmail.com: Siempre he sido y seré reticente frente a la inclusión de la categoría dentro del nombre, y esta no será la excepción. Sin embargo, leyendo las opiniones, dada la coyuntura y el afán de representar claramente la información, podríamos darnos esa licencia, aunque a largo plazo no sea lo más conveniente. Am Donnerstag, den 19.07.2012, 12:39 -0500 schrieb hyan...@gmail.com: Basado en el concepto de usabilidad y retórica cartográfica, me parece mejor brindarle explícitamente al usuario información de que se trata del Resguardo Indígena Quizgó; no veo redundancia, ya que uno comunica a las personas y el otro operará mejor en un escenario de interoperabilidad (consumo de datos por parte de aplicaciones de terceros). El día 19 de julio de 2012 12:29, Federico Explorador (Nevados.org) federico.explora...@nevados.org escribió: Hola: He hecho unos mapas provisionales con Maperitive, escalas 1:100.000 y 1:200.000, ver [1] Falta mapeo básico de pueblos, infraestructura y vías y completar los resguardos. @humano: he encontrado vías trazas tuyas sin etiquetear, me imagino que es trabajo en proceso y serán parte de un multipolígono para resguardo indígena? Nombres de los resguardos: sería bueno homogenizar el nombre: ponemos Resguardo indígena Quizgo o simplemente Quizgo. Me parece mejor incluir en el nombre Resguardo indígena, porque sino depende de la leyenda para saber de qué se trata. Pero también puede parecer redundante, qué opinan? Saludos, Federico [1] http://sdrv.ms/LvgTsw -Mensaje original- De: Fredy Rivera [mailto:fredyriv...@gmail.com] Enviado el: miércoles, 18 de julio de 2012 01:30 p.m. Para: OpenStreetMap Colombia Asunto: [Talk-co] Emergencia por hostilidades en el Norte del Cauca - Informe de situación No. 1 Hola En el documento que envia OCHA se puden identificar algunas necesidades donde nuestro equipo de maperos humanitario podria colaborar. salu2 -- Forwarded message -- From: Secretaria Tecnica SSH secreta...@colombiassh.org Date: 2012/7/18 Subject: Emergencia por hostilidades en el Norte del Cauca - Informe de situación No. 1 To: Sala de Situación s...@colombiassh.org PRIORIDADES / PUNTOS DESTACADOS La intensidad de las hostilidades en las últimas dos semanas, ha causado el desplazamiento masivo de cerca de 5.000 personas en cinco municipios del norte del Cauca, al menos 15 víctimas civiles y graves daños en viviendas y afectación a infraestructura. Se requieren medidas urgentes de protección de las comunidades indígenas y campesinas que se encuentran en la zona de riesgo. La emergencia ha superado las capacidades de autoridades municipales y departamentales. Las restricciones al acceso han limitado la respuesta a la emergencia. Para más información, consulte el informe en el siguiente enlace: http://www.colombiassh.org/site/IMG/pdf/OCHA_Colombia_-_Emergencia_en_Norte_ del_Cauca_-_18072012_final.pdf -- Cordialmente Secretaría Técnica SSH Tel. 6221100 Kr 13 No. 93- 12 Ofic. 402 secreta...@colombiassh.org http://www.colombiassh.org/site/ La Sala de Situación Humanitaria (SSH) es un esfuerzo interorganizacional para organizar información sobre necesidades de y respuestas a situaciones humanitarias. The Humanitarian Situation Room is a inter-organizational effort to
Re: [Talk-co] Emergencia por hostilidades en el Norte del Cauca - Informe de situación No. 1
Me encuentro con una duda. No puedo asumir que todos los boundary=protected_area, protected_class=24 sean resguardos, ¿o sí? ¿Corro el riesgo de mostrar territorios colectivos negros como Resguardo indígena Tal? Creo que al final no decidimos qué hacer para distinguirlos. Am Sonntag, den 22.07.2012, 12:03 -0500 schrieb hyan...@gmail.com: Sí, tienen razón --lapsus retoricus obsesivus--, es prioritario mantener la calidad en los datos. Para mejorar la retórica se puede renderizar con librerías diferentes a Mapnik que muestren claramente los contenidos con sus convenciones. El día 19 de julio de 2012 13:48, Ariel Nunez ingenieroar...@gmail.com escribió: Estoy de acuerdo con el man, digo Germán. No se puede poner el nombre de la categoría usando reglas de estilo? No se en maperitive, pero en SLD seria: sld:TextSymbolizer sld:Label ogc:PropertyNameResguardo Indígena+ name/ogc:PropertyName /sld:Label /sld:TextSymbolizer -Ariel. PD: Sin embargo, ya que botika existe, no habria problema en arreglarlo despues de la emergencia en caso de que se decida poner el largo ahora. 2012/7/19 Germán Márquez Mejía manch...@gmail.com: Siempre he sido y seré reticente frente a la inclusión de la categoría dentro del nombre, y esta no será la excepción. Sin embargo, leyendo las opiniones, dada la coyuntura y el afán de representar claramente la información, podríamos darnos esa licencia, aunque a largo plazo no sea lo más conveniente. Am Donnerstag, den 19.07.2012, 12:39 -0500 schrieb hyan...@gmail.com: Basado en el concepto de usabilidad y retórica cartográfica, me parece mejor brindarle explícitamente al usuario información de que se trata del Resguardo Indígena Quizgó; no veo redundancia, ya que uno comunica a las personas y el otro operará mejor en un escenario de interoperabilidad (consumo de datos por parte de aplicaciones de terceros). El día 19 de julio de 2012 12:29, Federico Explorador (Nevados.org) federico.explora...@nevados.org escribió: Hola: He hecho unos mapas provisionales con Maperitive, escalas 1:100.000 y 1:200.000, ver [1] Falta mapeo básico de pueblos, infraestructura y vías y completar los resguardos. @humano: he encontrado vías trazas tuyas sin etiquetear, me imagino que es trabajo en proceso y serán parte de un multipolígono para resguardo indígena? Nombres de los resguardos: sería bueno homogenizar el nombre: ponemos Resguardo indígena Quizgo o simplemente Quizgo. Me parece mejor incluir en el nombre Resguardo indígena, porque sino depende de la leyenda para saber de qué se trata. Pero también puede parecer redundante, qué opinan? Saludos, Federico [1] http://sdrv.ms/LvgTsw -Mensaje original- De: Fredy Rivera [mailto:fredyriv...@gmail.com] Enviado el: miércoles, 18 de julio de 2012 01:30 p.m. Para: OpenStreetMap Colombia Asunto: [Talk-co] Emergencia por hostilidades en el Norte del Cauca - Informe de situación No. 1 Hola En el documento que envia OCHA se puden identificar algunas necesidades donde nuestro equipo de maperos humanitario podria colaborar. salu2 -- Forwarded message -- From: Secretaria Tecnica SSH secreta...@colombiassh.org Date: 2012/7/18 Subject: Emergencia por hostilidades en el Norte del Cauca - Informe de situación No. 1 To: Sala de Situación s...@colombiassh.org PRIORIDADES / PUNTOS DESTACADOS La intensidad de las hostilidades en las últimas dos semanas, ha causado el desplazamiento masivo de cerca de 5.000 personas en cinco municipios del norte del Cauca, al menos 15 víctimas civiles y graves daños en viviendas y afectación a infraestructura. Se requieren medidas urgentes de protección de las comunidades indígenas y campesinas que se encuentran en la zona de riesgo. La emergencia ha superado las capacidades de autoridades municipales y departamentales. Las restricciones al acceso han limitado la respuesta a la emergencia. Para más información, consulte el informe en el siguiente enlace: http://www.colombiassh.org/site/IMG/pdf/OCHA_Colombia_-_Emergencia_en_Norte_ del_Cauca_-_18072012_final.pdf -- Cordialmente Secretaría Técnica SSH Tel. 6221100 Kr 13 No. 93- 12 Ofic. 402 secreta...@colombiassh.org http://www.colombiassh.org/site/ La Sala de Situación Humanitaria (SSH) es un esfuerzo interorganizacional para organizar información sobre necesidades de y respuestas a situaciones humanitarias. The Humanitarian Situation Room is a inter-organizational effort to organize information on needs and responses to humanitarian situations. Si no quisiera recibir esta información, por favor responda a este correo con el tema 'desuscribir'. Si quisiera ser agregado a la lista de
Re: [Talk-co] Emergencia por hostilidades en el Norte del Cauca - Informe de situación No. 1
Supongo podemos asumir que los territorios de las etnias en Colombia
se mapean usando cuatro (4) etiquetas:
boundary=protected_area
protected_class=24 --? = {1, 2, , 24, , n}; donde 24 =
Resguardo Indígena
ethnicity=yes
ethnic_group='Quizgó'
El día 22 de julio de 2012 13:30, Germán Márquez Mejía
manch...@gmail.com escribió:
Me encuentro con una duda. No puedo asumir que todos los
boundary=protected_area, protected_class=24 sean resguardos, ¿o sí?
¿Corro el riesgo de mostrar territorios colectivos negros como
Resguardo indígena Tal? Creo que al final no decidimos qué hacer para
distinguirlos.
Am Sonntag, den 22.07.2012, 12:03 -0500 schrieb hyan...@gmail.com:
Sí, tienen razón --lapsus retoricus obsesivus--, es prioritario
mantener la calidad en los datos. Para mejorar la retórica se puede
renderizar con librerías diferentes a Mapnik que muestren claramente
los contenidos con sus convenciones.
El día 19 de julio de 2012 13:48, Ariel Nunez
ingenieroar...@gmail.com escribió:
Estoy de acuerdo con el man, digo Germán.
No se puede poner el nombre de la categoría usando reglas de estilo?
No se en maperitive, pero en SLD seria:
sld:TextSymbolizer
sld:Label
ogc:PropertyNameResguardo Indígena+ name/ogc:PropertyName
/sld:Label
/sld:TextSymbolizer
-Ariel.
PD: Sin embargo, ya que botika existe, no habria problema en
arreglarlo despues de la emergencia en caso de que se decida poner el
largo ahora.
2012/7/19 Germán Márquez Mejía manch...@gmail.com:
Siempre he sido y seré reticente frente a la inclusión de la categoría
dentro del nombre, y esta no será la excepción. Sin embargo, leyendo las
opiniones, dada la coyuntura y el afán de representar claramente la
información, podríamos darnos esa licencia, aunque a largo plazo no sea
lo más conveniente.
Am Donnerstag, den 19.07.2012, 12:39 -0500 schrieb hyan...@gmail.com:
Basado en el concepto de usabilidad y retórica cartográfica, me
parece mejor brindarle explícitamente al usuario información de que se
trata del Resguardo Indígena Quizgó; no veo redundancia, ya que uno
comunica a las personas y el otro operará mejor en un escenario de
interoperabilidad (consumo de datos por parte de aplicaciones de
terceros).
El día 19 de julio de 2012 12:29, Federico Explorador (Nevados.org)
federico.explora...@nevados.org escribió:
Hola:
He hecho unos mapas provisionales con Maperitive, escalas 1:100.000 y
1:200.000, ver [1]
Falta mapeo básico de pueblos, infraestructura y vías y completar los
resguardos.
@humano: he encontrado vías trazas tuyas sin etiquetear, me imagino
que es
trabajo en proceso y serán parte de un multipolígono para resguardo
indígena?
Nombres de los resguardos: sería bueno homogenizar el nombre: ponemos
Resguardo indígena Quizgo o simplemente Quizgo. Me parece mejor
incluir
en el nombre Resguardo indígena, porque sino depende de la leyenda
para
saber de qué se trata. Pero también puede parecer redundante, qué
opinan?
Saludos,
Federico
[1] http://sdrv.ms/LvgTsw
-Mensaje original-
De: Fredy Rivera [mailto:fredyriv...@gmail.com]
Enviado el: miércoles, 18 de julio de 2012 01:30 p.m.
Para: OpenStreetMap Colombia
Asunto: [Talk-co] Emergencia por hostilidades en el Norte del Cauca -
Informe de situación No. 1
Hola
En el documento que envia OCHA se puden identificar algunas necesidades
donde nuestro equipo de maperos humanitario podria colaborar.
salu2
-- Forwarded message --
From: Secretaria Tecnica SSH secreta...@colombiassh.org
Date: 2012/7/18
Subject: Emergencia por hostilidades en el Norte del Cauca - Informe de
situación No. 1
To: Sala de Situación s...@colombiassh.org
PRIORIDADES / PUNTOS DESTACADOS
La intensidad de las hostilidades en las últimas dos semanas, ha
causado el
desplazamiento masivo de cerca de 5.000 personas en cinco municipios
del
norte del Cauca, al menos 15 víctimas civiles y graves daños en
viviendas y
afectación a infraestructura.
Se requieren medidas urgentes de protección de las comunidades
indígenas y
campesinas que se encuentran en la zona de riesgo.
La emergencia ha superado las capacidades de autoridades municipales y
departamentales. Las restricciones al acceso han limitado la respuesta
a la
emergencia.
Para más información, consulte el informe en el siguiente enlace:
http://www.colombiassh.org/site/IMG/pdf/OCHA_Colombia_-_Emergencia_en_Norte_
del_Cauca_-_18072012_final.pdf
--
Cordialmente
Secretaría Técnica SSH
Tel. 6221100
Kr 13 No. 93- 12 Ofic. 402
secreta...@colombiassh.org
http://www.colombiassh.org/site/
La Sala de Situación Humanitaria (SSH) es un esfuerzo
interorganizacional
para organizar información sobre necesidades de y
[Talk-dk] Familiesundspladser, skovstier osv
Hej kloge kortfolk. Vi er så heldige,at vores lokale skov, er et sandt mekka af shelters, teltpladser, sundhedspladser og gode sundhedsstier(total sundheds fetich) Jeg har styr på hvordan shelters og telpladser tegnes ind, med hvilket tag er passende for sundhedspladserne og hvordan kan jeg sørge for at de forskelleige ruter skiller sig ud? På forhånd tak for hjælpen:-) -- Med venlig hilsen Peter Lyberth ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-at] YA Hausnummern in Wien
On 21.07.12 12:35, Boris Cornet wrote: Andreas, ich fürchte, das was du da nicht magst ist state-of-the-art. Es hat sich vielleicht eingebürgert. Aber das zu entkoppeln (das Haus hat diese Nummer[n] - das Haus hat hier einen Eingang) ist viel sinnvoller. /al ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] startseite rendering rules?
Hallo! wer ist denn der ansprechpartner für die rendering rules, die hinter den tiles auf der startseite liegen? Das Stylesheet selbst ist da zu finden: https://trac.openstreetmap.org/browser/applications/rendering/mapnik Änderungswünsche werden als Ticket eingetragen: https://trac.openstreetmap.org/query?component=mapnikstatus=!closed Grüße Simon ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] YA Hausnummern in Wien
On 22.07.2012 10:07, Andreas Labres wrote: On 21.07.12 12:35, Boris Cornet wrote: Andreas, ich fürchte, das was du da nicht magst ist state-of-the-art. Es hat sich vielleicht eingebürgert. Aber das zu entkoppeln (das Haus hat diese Nummer[n]- das Haus hat hier einen Eingang) ist viel sinnvoller. Das finde ich inzwischen auch, nachdem mir lange Zeit die vom wien.at-Stadtplan vorgezeigte Variante besser gefallen hat. Es gibt zu OSM einen wesentlichen Unterschied: Der Stadtplan ist eine gerenderte Karte. Wir haben aber eine Datenbank, in der wir getrennte Informationen getrennt speichern können. Eine Hausnummer ist was anderes als ein Eingang und gehört daher separat gespeichert. Eine Anwendung kann diese Informationen dann immer noch zusammenmantschen, muss sie aber nicht. Die ewigen Hausnummerndebatten haben ihre Ursache darin, dass nicht genau definiert ist, was eine Hausnummer überhaupt ist. Wie soll man etwas speichern, von dem man nicht weiß, was es ist? Und wie soll eine Diskussion zu einem Ergebnis kommen, wenn keinem klar ist, worüber man diskutiert? Also was ist eine Hausnummer? Ist es die Nummer eines Hauses oder eines Grundstücks? Nur eins ist sicher: Eine Hausnummer ist kein Eingang! Meiner Meinung nach ist eine Hausnummer und allgemein eine Adresse kein eigenständiges Objekt, sondern nur ein Attribut eines Objektes, z.B. eines Hauses oder Grundstücks oder Shops. Darum ist es eigentlich ein Blödsinn, die Hausnummer als eigenständigen Node zu setzen. Die Hausnummer gehört aufs Gebäude/Grundstück/wasauchimmer gesetzt. Dabei haben wir natürlich das von dir angesprochene Eckhausproblem. Ein Haus mit 2 verschienenen Adressen. Müssen wir deswegen 2 Adressnodes anlegen? Ich sage nein! Es ist nämlich das gleiche Problem, wie wenn ein Objekt 2 Namen hat. Wir legen das Objekt dann auch nicht 2x an, sondern setzen ein name=* und ein alt_name=*. Genauso können wir das mit den Adressen machen: addr:street=* + addr:housenumber=* addr1:street=* + addr1:housenumber=* usw. Damit können immer die gesamten Adressangaben aufs Gebäude gesetzt werden, und so können Anwendungen zu einer Adresse (auch Alternativadresse) automatisch alle Gebäudeeingänge finden. Wenn euch die Idee zusagt, kann ich gern ein Proposal anlegen. Das ist nötig, damit die Syntax dann auch wirklich ausgewertet wird. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] YA Hausnummern in Wien
Guten Tag! Heute (22. Juli) um 11:42 meinte Friedrich Volkmann: Dabei haben wir natürlich das von dir angesprochene Eckhausproblem. Ein Haus mit 2 verschienenen Adressen. Müssen wir deswegen 2 Adressnodes anlegen? Ich sage nein! Es ist nämlich das gleiche Problem, wie wenn ein Objekt 2 Namen hat. Wir legen das Objekt dann auch nicht 2x an, sondern setzen ein name=* und ein alt_name=*. Damit können immer die gesamten Adressangaben aufs Gebäude gesetzt werden, und so können Anwendungen zu einer Adresse (auch Alternativadresse) automatisch alle Gebäudeeingänge finden. Ich muss ich dir recht geben, so ist es logisch stringent. (Danke Mr. Spock ;-) Überhaupt nicht logisch stringent ist aber deine Idee des Taggings: addr:street=* + addr:housenumber=* addr1:street=* + addr1:housenumber=* Du willst also ein Programm zwingen, eine unvorhersehbare Zahl von unterschiedlichen Tags auszuwerten? Eine kleine, aber entscheidende Verbesserung wäre: addr:1:street addr:2:street Das hat den Vorteil, dass es universell ist (also nicht nur auf den addr namespace beschränkt bleiben muss) und wesentlich einfacher zu parsen ist. Wenn euch die Idee zusagt, kann ich gern ein Proposal anlegen. Das ist nötig, damit die Syntax dann auch wirklich ausgewertet wird. Ja, bitte nur zu, sofern du den Einwand oben akzeptierst. -- Liebe Grüße, Boris ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] Jakobsweg
Jetzt, wo wir sowieso alle Routenrelationen überprüfen müssen, ist vielleicht der richtige Zeitpunkt um endlich mal mit den redundanten Jakobswegen aufzuräumen. Es gibt eine Relation http://www.openstreetmap.org/browse/relation/2073724 und mehrere Relationen für Abschnitte davon. Siehe: http://forum.openstreetmap.org/viewtopic.php?pid=227055#p227055 Killen wir die große Relation oder die Abschnittsrelationen? Oder wandeln wir die große in eine Metarelation um? -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
