Re: [Talk-hr] OSM aktivnost po gradovima
On 3.10.2010 21:33, Hrvoje Bartolin wrote: Mene bi više zanimalo koje prometnice ili dijelove RH još treba mappirati. Da li bi se dalo nešto izvući iz popisa cesata i onda križati da vidimo što je još ostalo? http://narodne-novine.nn.hr/clanci/sluzbeni/2010_02_17_410.html Ovaj popis u NN je vrlo točan ali neprecizan. Jako je teško iz njega zaključiti gdje se točno cesta grana i kojim putem dolazi do cilja. Čini mi se da je to jedini službeni opis državnih i drugih cesta. No našao sam nešto drugo: http://en.wikipedia.org/wiki/State_roads_in_Croatia#State_roads Ovo je neslužbeno, no svaka cesta je opisana vrlo precizno, svako križanje je opisano sa kojim cestama se sijeće. Ovo nije pisao netko čitajuči neku online kartu već netko tko raspolaže sa preciznijim službenim podacima. Mislim da je ovo treba iskoristiti, no možda ipak pitati autora od kuda mu toliko detaljni opisi. Tihomir ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
Re: [talk-ph] Digital Topographic Mapping of Mindanao
Further information about the terms of reference of this project is in this link http://medco.gov.ph/medcoweb/uploads/mtmp/mtmp_tor_psctcc.pdf --bunny --- On Tue, 12/10/10, Eugene Alvin Villar sea...@gmail.com wrote: From: Eugene Alvin Villar sea...@gmail.com Subject: Re: [talk-ph] Digital Topographic Mapping of Mindanao To: maning sambale emmanuel.samb...@gmail.com Cc: osm-ph talk-ph@openstreetmap.org Received: Tuesday, 12 October, 2010, 12:54 PM Deja vu: http://www.mail-archive.com/talk-ph@openstreetmap.org/msg01656.html Does this mean that this project is still in the planning stage after 1 year? On Tue, Oct 12, 2010 at 12:24 PM, maning sambale emmanuel.samb...@gmail.com wrote: Found this news on Sorbi's news blog: http://www.geomanila.com/2010/09/digital-topographic-mapping-of-mindanao.html Finally, our half-a-century old topo maps will be updated. -- cheers, maning ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] Digital Topographic Mapping of Mindanao
Here's what it says on the last page: Other Stakeholders agencies and institutions will be invited to the TCC meeting for consultation as need arises. These would include but not limited to the following: [...] * Private individuals or institutions with expertise in GIS and mapping methodologies. I think OpenStreetMap Philippines would be a good fit. :-D On Wed, Oct 13, 2010 at 3:44 PM, Leonard Soriano banito_pi...@yahoo.com wrote: Further information about the terms of reference of this project is in this link http://medco.gov.ph/medcoweb/uploads/mtmp/mtmp_tor_psctcc.pdf --bunny --- On Tue, 12/10/10, Eugene Alvin Villar sea...@gmail.com wrote: From: Eugene Alvin Villar sea...@gmail.com Subject: Re: [talk-ph] Digital Topographic Mapping of Mindanao To: maning sambale emmanuel.samb...@gmail.com Cc: osm-ph talk-ph@openstreetmap.org Received: Tuesday, 12 October, 2010, 12:54 PM Deja vu: http://www.mail-archive.com/talk-ph@openstreetmap.org/msg01656.html Does this mean that this project is still in the planning stage after 1 year? On Tue, Oct 12, 2010 at 12:24 PM, maning sambale emmanuel.samb...@gmail.com wrote: Found this news on Sorbi's news blog: http://www.geomanila.com/2010/09/digital-topographic-mapping-of-mindanao.html Finally, our half-a-century old topo maps will be updated. -- cheers, maning ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [OSM-talk-be] mapping on horseback
Please give your remarks on http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Bus_stopsand http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Bus_and_tram_lines ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] mapping on horseback
Seems fine to me. Jo 2010/10/13 Ivo De Broeck ivo.debro...@gmail.com Please give your remarks on http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Bus_stopsand http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Bus_and_tram_lines ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] samenwerking met De Lijn: zij zien dat NIET zitten
Lees de tweede lijn van het gequote antwoord in de eerste mail van deze thread nog 's. Best effort doesn' t cut it... Jo Op 13 oktober 2010 17:15 schreef Philippe Duthoit philippe.duth...@gmail.com het volgende: kun je de Lijn niet voorstellen dat dit onder best-effort kan vallen (net zoals men bij dsl lijnen doet) ? 2010/10/8 Jo winfi...@gmail.com Het antwoord van De Lijn dat ' k hier gepost heb, komt eigenlijk neer op: het ziet er wel interessant uit wat jullie doen, maar wij zien het niet zitten om jullie bij jullie inspanningen te helpen. Ook al zou dat betekenen dat de informatie waarover jullie beschikken op kortere termijn accurater zou zijn i,p,v, op langere termijn. Om ervoor te zorgen dat het onmogelijk wordt om tot een overenkomst te komen, hebben we de volgende voorwaarde bedacht (OK, nogal cynisch): jullie moeten kunnen GARANDEREN dat alle wijzigingen (en dat zijn er veel) meteen worden verwerkt in jullie databank, zodat mensen niet kunnen komen klagen bij De Lijn als ze verkeerde informatie zouden krijgen. Het is inderdaad ook een probleem dat we niet weten hoe, hetgeen zij aanleveren, eruit zou zien. Ik had graag ons model daar zoveel mogelijk op afgesteld. En wat voor garanties kunnen we hen uiteindelijk geven? Als wij alles mooi importeren en in orde maken en dan komt er iemand langs die alles overhoop gooit, met een of andere edit, goedbedoeld of kwaadwillend (vandalisme) en net op dat moment baseert iemand zijn 'vervoersbeslissing' op onze informatie. Er zou eigenlijk een tussenstuk/project moeten bestaan, dat die garanties wel kan geven. Iemand interesse om dat op te starten? Nu, ik blijf het eigenaardig vinden dat de discussie niet over de licentievoorwaarden gaat. Neem nu dat er zo'n project zou bestaan dat alle informatie van De Lijn automatisch omzet naar iets 'begrijpelijk' en dat opslaat in een databank. Een script dat 2x per week alles afhaalt met FTP bij De Lijn en de tabellen aanpast. Waar er aanpassingen zijn, wordt dit zo aangeduid. Het project maakt gebruik van OdBL, of hoe die licentie ook heet. Dan kan Openstreetmap.org en elk project dat dat wil, daar die informatie komen ophalen. De Lijn is blij want ze hebben de garantie dat in die tussendatabank alle informatie compleet up to date is. Openstreetmap en z' n vrijwilligers zijn blij, want het monikkenwerk wordt nu een stuk gemakkelijker. De gebruikers zijn blij want ze hebben hun informatie. Op dat tussenproject met grote accuraatheid, op Openstreetmap.org onder hun eigen verantwoordelijkheid. Zo'n project opstarten zal wel niet overdreven moeilijk zijn. Wie gaat de server hosten? Voorzien we meer dan 1 server die gerepliceerd worden? Zouden we dat eventueel op die Nederlandse server kunnen hosten? Ik kan waarschijnlijk wel een importscript in elkaar boksen dat wat De Lijn aanlevert, omzet in databanktabellen waar OSM mee verder kan, nadien. Jo Op 8 oktober 2010 13:12 schreef Ben Laenen benlae...@gmail.com het volgende: Jo wrote: Ik heb De Lijn nog 's gekontakteerd ivm informatie over hun haltes en evt. busroutes. Ik kreeg dezelfde standaardmail als iemand anders op deze mailing list, wat me in eerste instantie wel bemoedigend leek. Daarin vragen ze echter om 'garanties'. Iets wat we hen gewoonweg niet kunnen geven. Ze zijn bang voor klachten die bij De Lijn zouden toekomen als mensen via OSM hun reisweg zouden plannen en dit fout zou lopen. Jammer, maar misschien kan je hen iets anders vragen als het echt niet lukt: namelijk of we gewoon de routes van de kaarten die zij ter beschikking stellen via kaarten mogen overnemen? Voor busroutes maakt het toch niet zo veel uit of we de originele dataset hebben of de kaartjes (laatste zijn zelfs beter want ik denk niet dat de dataset de exact bevat welke straten exact genomen moet worden), want er gaat volgens mij toch geen manier zijn om een dataset van routes rechtstreeks te importeren naar routerelaties. Maar misschien moeten we eens nadenken over welke garanties we kunnen geven, en dat begint dan bij het nadenken over wat in hun dataset juist zit. Bushaltes en buslijnen in de vorm van een lijst bushaltes? In de tijdstabellen zijn we op dit moment nog niet geïnteresseerd. Is dat dan eigenlijk zo moeilijk om te updaten? Een verzameling van nodes en daarop de routerelaties (die dan bij import enkel nodes bevat), dat lijkt me niet onoverkomelijk om dat te onderhouden, het zou zelfs volledig automatisch kunnen (maar er moet wel een klein beetje infrastructuur voor opgesteld worden om te weten welke dingen je hebt op de kaart gezet). De enige interactie zou dan zijn dat iemand bij ontvangst van nieuwe data dat in het uploadscript steekt waarna dat dan zijn werk doet. Wat betreft routerelaties zou ik het zo doen: bij import zijn dat dus gewoon nodelijsten van alle bushaltes. Nu kunnen mappers de routes zelf aanvullen door de juiste ways toe te voegen. Wat nu als bij
Re: [OSM-legal-talk] legal FAQ license
On Wed, Oct 13, 2010 at 2:05 PM, David Groom revi...@pacific-rim.net wrote: - Original Message - From: M?rtin Koppenhoefer dieterdre...@gmail.com To: Licensing and other legal discussions. legal-talk@openstreetmap.org Sent: Wednesday, October 13, 2010 3:44 PM Subject: [OSM-legal-talk] legal FAQ license reading the legal FAQ for the license change: http://wiki.openstreetmap.org/wiki/Open_Data_License_FAQ there is a paragraph that looks strange to me: ... - we may take the view that those who have made small contributions, but cannot be contacted, would relicence their data under the new licence. We will enable them to contact us at a later date. this part looks like a problem to me, as it is opt-out instead of the always proclaimed opt-in, or have I misunderstood this? Or is this refering to anonymous edits only? Unfortunately the wiki seems to offer conflicting views on what might happen. The section you quoted [1] does indeed seem to indicate that contributions from some people who have not responded will be left in the database. However further up the same page [2] it says remove any data from any users who do not respond or respond negatively (the hard bit) , and again here [3] it says What do we do with the people who have Declined or not responded? Their contributions would not be available under the future ODbL version of the database. David David, what would you suggest? Can you see a situation where discarding the data is not required in the case of non-response? For example, a 'bot that does nothing but fix spelling in keys, changes Amenity to amenity, but the 'bot does not answer the mandatory relicensing question. Should we revert their changes back to Amenity? As another example, a user adds one POI, perhaps their business, to OSM and nothing else. They never respond. Do we remove the data? As another example, an editor makes many mass edits around the planet, arbitrarily changing keys/values to match their recent wiki postings, then answers no to relicensing. What do you suggest is the right answer for each of these situations? Would your answer have universal support from the community? Can you create some other situations and responses that will find universal support from the community? ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] legal FAQ license
On Wed, Oct 13, 2010 at 3:21 PM, Richard Weait rich...@weait.com wrote: For example, a 'bot that does nothing but fix spelling in keys, changes Amenity to amenity, but the 'bot does not answer the mandatory relicensing question. Should we revert their changes back to Amenity? As another example, a user adds one POI, perhaps their business, to OSM and nothing else. They never respond. Do we remove the data? As another example, an editor makes many mass edits around the planet, arbitrarily changing keys/values to match their recent wiki postings, then answers no to relicensing. What do you suggest is the right answer for each of these situations? Eh, I'd say revert them, and then run a bot to make the changes yourself. Not so much because it's legally or morally required but just because it's easier than making special exceptions. ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] legal FAQ license
Frederik Ramm frede...@... writes: I think you have understood this all right. In my eyes there's a wide band between clearly non-copyrightable edits on one side (which we could legally keep in OSM even if the person who added them said no - but we're unlikely to exercise that right) and edits that are clearly works on the other (which are thus copyrightable in some countries). In between there may well lie some edits that are extremely unlikely to qualify as a work in terms of IP law, but where we would still remove them if the person who added them were to ask us to do it. For these, I think the opt-out mechanism is morally acceptable. And of course we are using the same rules for taking and giving, or? Same amounts of data we consider non-copyrightable and keep therefore in the database can be taken out from the new ODbl-OSM database as if they were PD? And even store masses of separate extracts into one database because that's what we would do ourselves? ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] legal FAQ license
Jukka, Jukka Rahkonen wrote: And of course we are using the same rules for taking and giving, or? Same amounts of data we consider non-copyrightable and keep therefore in the database can be taken out from the new ODbl-OSM database as if they were PD? And even store masses of separate extracts into one database because that's what we would do ourselves? I'm not sure I quite understand. Our new license does have a provision that allows using non-substantial extracts without regard to the license. This can be viewed as similar to what I described above, although there is a big difference. If one million users each make a non-copyrightable contribution to OSM under CC-BY-SA then I can take those one million contributions and use them in any way I want because if they are not copyrightable then CC-BY-SA doesn't have any effect. However if I put those same one million contributions into a database protected by ODbL, then they are likely to form a substantial extract and thus they cannot be extracted outside of ODbL terms. (On the other hand, it is well possible that there is an individual contribution which is copyrightable but still doesn't form a substantial extract.) ODbL's concept if you take a lot of insubstantial extracts and combine them then they again form a substantial extract does not apply to copyright of individual contributions made under CC-BY-SA - if you take lots of non-copyrighted bits submitted by various users and combine them then they don't suddenly become copyrighted - or maybe they do, but then it's your copyright and not that of the original contributors (think of tearing a magazine to shreds and then gluing together a nice picture from the coloured pieces of paper). Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] legal FAQ license
Andrzej, andrzej zaborowski wrote: You may also want to take into account the automatic database rights in some users' contributions (even if not copyrightable), which iirc are not disclaimed by CC-By-SA 2 unported. If we assume there to be such rights (and there might well be!), would this not mean that we'd have to remove their contribution from OSM immediately because the required permissions for re-use/distribution have not been granted? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] legal FAQ license
- Original Message - From: Richard Weait rich...@weait.com To: Licensing and other legal discussions. legal-talk@openstreetmap.org Sent: Wednesday, October 13, 2010 11:32 PM Subject: Re: [OSM-legal-talk] legal FAQ license On Wed, Oct 13, 2010 at 4:05 PM, David Groom revi...@pacific-rim.net wrote: - Original Message - From: Richard Weait rich...@weait.com David, what would you suggest? Can you see a situation where discarding the data is not required in the case of non-response? My first suggestion would be that the wiki is corrected so that it does not contradict itself. [ ... ] Let's improve that wiki page. Let's clarify exactly which edits need permission to be promoted to ODbL. For example, a 'bot that does nothing but fix spelling in keys, changes Amenity to amenity, but the 'bot does not answer the mandatory relicensing question. Should we revert their changes back to Amenity? As another example, a user adds one POI, perhaps their business, to OSM and nothing else. They never respond. Do we remove the data? As another example, an editor makes many mass edits around the planet, arbitrarily changing keys/values to match their recent wiki postings, then answers no to relicensing. What do you suggest is the right answer for each of these situations? Would your answer have universal support from the community? Can you create some other situations and responses that will find universal support from the community? Is there some OSM contribution or edit that is so mechanical and/or so insignificant that it need never be considered for copyright or database right? If so how do we recognize it? How do we recognize the boundary between insignificant and significant? Copyright law suggests that there is a minimum size for a work to gain copyright protection. It's my understanding that a book title is too short for copyright protection, while a chapter, page or even paragraph would gain copyright protection. European Database Directive suggests that there is some insignificant amount of data that can be used from an otherwise database right protected database without violating that database right. My position would be simple. If a user has not agreed to the relicencing then his/her edits should not remain in the database after any switchover. This has a number of advantages. 1) its morally correct. 2) its simple to understand 3) its easier to code for Now some people will argue that there some OSM contributions or edit that..is so insignificant that it need never be considered for copyright or database right. Well if it is so insignificant then not including it in the database after any switchover will have an insignificant effect, and so surely no one will worry if its not there. If people worry about the absence of the data then that surely lends weight to the argument that it was significant in the first place. Or can the data be insignificant enough not to warrant any copyright protection, yet at the same time significant enough that it should be left in the database. David Where do you suggest that these lines be drawn? Take a position. Let's run your ideas up the flagpole and see if we can get the community to salute. ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] legal FAQ license
On Wed, Oct 13, 2010 at 4:50 PM, Frederik Ramm frede...@remote.org wrote: If one million users each make a non-copyrightable contribution to OSM under CC-BY-SA then I can take those one million contributions and use them in any way I want because if they are not copyrightable then CC-BY-SA doesn't have any effect. However if I put those same one million contributions into a database protected by ODbL, then they are likely to form a substantial extract and thus they cannot be extracted outside of ODbL terms. How does one go about turning an ordinary database into a database protected by ODbL? ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] Proposal: winter roads
On Sat, 9 Oct 2010 12:56:07 +0400 Gleb Smirnoff gleb...@glebius.int.ru wrote: Dave, On Sat, Oct 09, 2010 at 12:13:14AM +0100, Dave F. wrote: D The wiki page describes subjective information. D D Unless it's actually closed by authority don't say it's D impassible. For instance in defense of your argument that it's D impassable you say the average speed is 0.5km/h. This comment D proves the it *is* passable, just very slowly. No this one is not passable, and vast majority of other winter roads are not passable, too. Let me explain again: first, the photo is taken at a piece of winter road that is reachable by 4x4 vehicle. Evidently, I can't make a photo of a vehicle at a place where vehicle can't get to. If I walk there by foot, and make photo w/o vehicle on road, the photo won't tell anything: an untouched muskeg swamp looks like a meadow. Dmitri has added another photo of winter road, it demonstates better the terrain: http://wiki.openstreetmap.org/wiki/Proposed_features/surface:winter_road It is no coincedence there is a Russian word, rasputitsa, which means roadlessness... __ Morten Juhl-Johansen Zölde-Fejér http://writtenandread.net * mor...@writtenandread.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Tagging] Introducing Taginfo
On Tue, Oct 12, 2010 at 10:58:34PM +0200, Sebastian Klein wrote: Jochen Topf wrote: On Tue, Oct 05, 2010 at 04:46:26PM +0200, Pieren wrote: If I could have one request, it would be nice to see the amount of different contributors using the same tag. This to distinguish between quantity and popularity. I know it might be challenging since we should only count the user of the tag creation in the element history... On http://taginfo.openstreetmap.de/keys there is a 'users' column. But this doesn't look at the history, only the current use. It gives you still some idea, but its not perfect. But reading the history is not an option at the moment, because this would need far more resources. The number of users is also taking into account when creating the tag cloud for the home page. This way some tags from imports which are very common in the database but have a small user count are downgraded. :-) Jochen Is it planned to have users count for the individual key pages? It can be interesting to see how popular common_key=some_exotic_value really is. Sometimes it is used frequently, but by a single mapper only. Users are counted for keys only and not for key=value combinations, because there are just too many key=value combinations and too many users to do this counting efficiently. At least I haven't come up with an idea how to do this. maybe somebody else can. Currently for every key I create a hash with all users in it, that use this key. When I am through all the tags, I count how many elements there are in each hash and thats the number of users for this key. This is rather inefficient and could probably be improved using some clever hashing for the price of some inaccuracies (which don't matter too much in this case, all we really want to know is roughly how many users there are). But even when this is done in a more efficient manner, we can't to that for 50 million different key=value combinations. We might be able to do it for the more popular combinations, after all if a key=value combination only appears twice in the whole database, it doesn't really matter if that was from one or two users. Currently Taginfo needs about 10G RAM to do all the statistics it does. Thats already too much in my opinion. So until somebody finds a clever way how to reduce the memory needed for these kinds of statistics, they can not be done. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Ongoing bulk uploads of GPS traces?
On 13/10/10 4:39 PM, Elizabeth Dodd wrote: Would you consider uploading the traces to an independent point, specifying the licence of the traces and giving permission for them to be traced into OSM / other maps (you specify what) and perhaps this could then be downloaded as a separate layer into editors? Yes, I could do that, absolutely. Do you think this is a better option? It would make the traces less apparent to lots of people (i.e. they wouldn't be included when someone clicks the Also get GPS traces checkbox in Merkaartor for example), but I guess I could advertise their existence to Australian mappers etc. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Ongoing bulk uploads of GPS traces?
On 13/10/2010 08:50, Sam Wilson wrote: 1. We use OSM maps for navigation, and so management are quite able to see the value that could arise from our giving this data to OSM, because it would make the maps better. But there is a bit of a gap between lots-of-GPS-traces and lots-of-well-tagged-roads! What can I do to bridge this gap? (I mean, trace over the GPS trace, I know, but that's going to leave a lot of 'highway=road' tags; is that okay?) That's fine -- it's much better than nothing 2. What form of permission do I need to get from management, and where does it get saved? Is there a pro forma letter somewhere? What licence do we release the data under? You'd be releasing the data under CC-BY-SA and ODbL. If you are acting on behalf of the copyright owner, then you don't need to add any further documentation -- simply uploading the data is enough to show you agree to the licences. 3. Is a single daily trace suitable? I mean, all vehicles' traces put together in one file and uploaded (under, I guess, a separate account -- but still owned by me)? Or is there some automatic way of doing this? A separate account for the traces may well be a good idea. As for aggregating the traces, I don't see any benefit to OSM of doing that, especially if it involves you doing more work. If it's the effort of uploading multiple traces that worries you, there's an Alpha-quality Java utility that I'm happy to help you to use: http://www.chainring.co.uk/Tracey.jar But really: is this worthwhile? Will my company benefit? Will OSM benefit? Yes. More source data is always good, especially if it's based on real movements. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Ongoing bulk uploads of GPS traces?
On Wed, 13 Oct 2010 16:53:59 +0800 Sam Wilson s...@archives.org.au wrote: On 13/10/10 4:39 PM, Elizabeth Dodd wrote: Would you consider uploading the traces to an independent point, specifying the licence of the traces and giving permission for them to be traced into OSM / other maps (you specify what) and perhaps this could then be downloaded as a separate layer into editors? Yes, I could do that, absolutely. Do you think this is a better option? It would make the traces less apparent to lots of people (i.e. they wouldn't be included when someone clicks the Also get GPS traces checkbox in Merkaartor for example), but I guess I could advertise their existence to Australian mappers etc. There was a Russian transport mob who managed to completely overload the track upload system trying to put up gps traces to the main database. Separate hosting would keep that from happening - WA is on the same huge scale as Russia. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Ongoing bulk uploads of GPS traces?
Elizabeth Dodd wrote: There was a Russian transport mob who managed to completely overload the track upload system trying to put up gps traces to the main database. Separate hosting would keep that from happening - WA is on the same huge scale as Russia. Different issue. The issue with the Russian transport mob is that they uploaded the tracks all in one go with no delay between them. Simply putting sleep 60 in your upload script between each track fixes this. Sam: this is great. Go for it. cheers Richard -- View this message in context: http://gis.638310.n2.nabble.com/Ongoing-bulk-uploads-of-GPS-traces-tp5629920p5630878.html Sent from the General Discussion mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-legal-talk] legal FAQ license
reading the legal FAQ for the license change: http://wiki.openstreetmap.org/wiki/Open_Data_License_FAQ there is a paragraph that looks strange to me: ... - we may take the view that those who have made small contributions, but cannot be contacted, would relicence their data under the new licence. We will enable them to contact us at a later date. this part looks like a problem to me, as it is opt-out instead of the always proclaimed opt-in, or have I misunderstood this? Or is this refering to anonymous edits only? cheers, Martin ___ legal-talk mailing list legal-t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
[OSM-talk] Osmand question regarding overlaping
Hi, apologies if this is the wrong forum for this question. I'm using osmand and successfully downloaded all the tiles for my city and it works great. Now I want to do the same for the whole country (I'm in spain). Obviously the country will include tge city within it. How does osmand handle this overlapping? Is it a problem our is it smart enough to handle it properly. Also, it's there a repository somewhere or perhaps a torrent with maps for different countries ready for download rather than using the map creator program? Thanks in advance! ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Ongoing bulk uploads of GPS traces?
2010/10/13 Sam Wilson s...@archives.org.au: Hi, I work for a company in Western Australia that has a dozen or so vehicles traveling all over regional WA and all equipped with GPS trackers, taking waypoints at 30s intervals. I am going to be allowed to upload the data to OSM. I'm just wondering what issues I'm facing... I feel that 30s per trackpoint is not quite much. For a truck travelling at 80km per hour this would be one trackpoint every 667 metres. Not really enough to get even the idea where a curve is, but OK if the streets are perfectly straight and there is nothing around ;-) Cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Ongoing bulk uploads of GPS traces?
On Wed, Oct 13, 2010 at 4:04 PM, M∡rtin Koppenhoefer dieterdre...@gmail.com wrote: 2010/10/13 Sam Wilson s...@archives.org.au: Hi, I work for a company in Western Australia that has a dozen or so vehicles traveling all over regional WA and all equipped with GPS trackers, taking waypoints at 30s intervals. I am going to be allowed to upload the data to OSM. I'm just wondering what issues I'm facing... I feel that 30s per trackpoint is not quite much. For a truck travelling at 80km per hour this would be one trackpoint every 667 metres. Not really enough to get even the idea where a curve is, but OK if the streets are perfectly straight and there is nothing around ;-) And perfectly fine if there are multiple journeys along the same route. This data is definitely of value. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Ongoing bulk uploads of GPS traces?
On Wed, Oct 13, 2010 at 3:50 AM, Sam Wilson s...@archives.org.au wrote: Hi, I work for a company in Western Australia that has a dozen or so vehicles traveling all over regional WA and all equipped with GPS trackers, taking waypoints at 30s intervals. I am going to be allowed to upload the data to OSM. I'm just wondering what issues I'm facing... Thank you for taking the initiative arrange this with your company. If you get the opportunity to change your data acquisition to one track point per second you'll find the traces much nicer for creating junctions, ramps, exits, fuel stations etc. Are you really taking waypoints every 30 second or track points? I've always worked with tracks / track points. 1. We use OSM maps for navigation, and so management are quite able to see the value that could arise from our giving this data to OSM, because it would make the maps better. But there is a bit of a gap between lots-of-GPS-traces and lots-of-well-tagged-roads! What can I do to bridge this gap? (I mean, trace over the GPS trace, I know, but that's going to leave a lot of 'highway=road' tags; is that okay?) This is typical for mapping new areas. You'll make improvements with each pass. Highway=road first, perhaps junctions as you add crossing traces next, a new amenity=fuel when you stop at a new place... Improved road classifications as driver observations and memory allow. 3. Is a single daily trace suitable? I mean, all vehicles' traces put together in one file and uploaded (under, I guess, a separate account -- but still owned by me)? Or is there some automatic way of doing this? Individual traces seems a better approach to me. I've used combined traces but recall that some tools did not handle the split between traces very well. One left a connection between the end one one trace and the start of the next. Another ignored traces after the first trace. I don't recall which tools these were; it was some time ago. But really: is this worthwhile? Will my company benefit? Will OSM benefit? Is this worthwhile? It seems to be exactly what OSM is for. Additional contributors, participating in OpenStreetMap by telling us more about their part of the World. Perfect. Tell some of your trusted colleagues how much fun it is too. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-legal-talk] legal FAQ license
Hi, M∡rtin Koppenhoefer wrote: reading the legal FAQ for the license change: http://wiki.openstreetmap.org/wiki/Open_Data_License_FAQ there is a paragraph that looks strange to me: ... - we may take the view that those who have made small contributions, but cannot be contacted, would relicence their data under the new licence. We will enable them to contact us at a later date. this part looks like a problem to me, as it is opt-out instead of the always proclaimed opt-in, or have I misunderstood this? I think you have understood this all right. In my eyes there's a wide band between clearly non-copyrightable edits on one side (which we could legally keep in OSM even if the person who added them said no - but we're unlikely to exercise that right) and edits that are clearly works on the other (which are thus copyrightable in some countries). In between there may well lie some edits that are extremely unlikely to qualify as a work in terms of IP law, but where we would still remove them if the person who added them were to ask us to do it. For these, I think the opt-out mechanism is morally acceptable. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ legal-talk mailing list legal-t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] Ongoing bulk uploads of GPS traces?
On Wed, 13 Oct 2010 17:04:20 +0200 M∡rtin Koppenhoefer dieterdre...@gmail.com wrote: OK if the streets are perfectly straight and there is nothing around ;-) Perfect for rural and remote Western Australia then. (This is the part of the world that owns the longest railway straight in existence) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Ongoing bulk uploads of GPS traces?
On 13 October 2010 20:35, Elizabeth Dodd ed...@billiau.net wrote: On Wed, 13 Oct 2010 17:04:20 +0200 M∡rtin Koppenhoefer dieterdre...@gmail.com wrote: OK if the streets are perfectly straight and there is nothing around ;-) Perfect for rural and remote Western Australia then. (This is the part of the world that owns the longest railway straight in existence) I agree, plus if the traces are numerous, the coverage could end up being quite good. In addition, they might be good enough to provide some initial sketch of roads. Emilie Laffray ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Gov access report for September
Hi all Attached is the government access report for September. I've added a 'licensed' column, but the only information I have to fill this in is the set of IP addresses in the WMS whitelist file; these don't always identify agencies, and I'm guessing that not all licensees pay for WMS access, so all we can deduce from this is that the ones marked 'Yes' are definitely licensed. Apologies for the delay in getting this done. Cheers b -- Ben Last Development Manager NearMap.com reports2010-09-01-2010-10-01.xlsx Description: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Ongoing bulk uploads of GPS traces?
On 2010-10-13 5:12 PM, Jonathan Bennett wrote: You'd be releasing the data under CC-BY-SA and ODbL. If you are acting on behalf of the copyright owner, then you don't need to add any further documentation -- simply uploading the data is enough to show you agree to the licences. Great! I might just get a letter from management as well, stating that they're permitting me to do this; never know what might happen in the future. A separate account for the traces may well be a good idea. As for aggregating the traces, I don't see any benefit to OSM of doing that, especially if it involves you doing more work. If it's the effort of uploading multiple traces that worries you, there's an Alpha-quality Java utility that I'm happy to help you to use: http://www.chainring.co.uk/Tracey.jar I've been looking into the format that the traces will come in, and it looks like a weekly NMEA dump is going to be the least work for me -- a single file, with all vehicles, that I can gpsbabel into GPX and upload. But I'm open to suggestions on that - Sam. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Ongoing bulk uploads of GPS traces?
On 2010-10-14 3:35 AM, Elizabeth Dodd wrote: On Wed, 13 Oct 2010 17:04:20 +0200 M∡rtin Koppenhoeferdieterdre...@gmail.com wrote: OK if the streets are perfectly straight and there is nothing around ;-) Perfect for rural and remote Western Australia then. (This is the part of the world that owns the longest railway straight in existence) Yep, perfectly straight and nothing around: that's the WA wheatbelt exactly! ;-) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Ongoing bulk uploads of GPS traces?
On 2010-10-14 1:35 AM, Richard Weait wrote: Thank you for taking the initiative arrange this with your company. If you get the opportunity to change your data acquisition to one track point per second you'll find the traces much nicer for creating junctions, ramps, exits, fuel stations etc. I'll look into the options, but I seem to remember hearing that we were already on the highest frequency possible (with, I guess, our pricing plan). Are you really taking waypoints every 30 second or track points? I've always worked with tracks / track points. Ah, well, yes: I'm probably just displaying my ignorance. ;-) What's the difference between a waypoint and a track point? This is typical for mapping new areas. You'll make improvements with each pass. Highway=road first, perhaps junctions as you add crossing traces next, a new amenity=fuel when you stop at a new place... Improved road classifications as driver observations and memory allow. I should make one point clear: I'm not actually surveying these places. I sit in an office in Perth, and don't really know the country through which the vehicles travel. I'll just be making the best of the GPS tracks and Yahoo imagery. Obviously it'd be better to have people who actually *know* the country editing the map, but I don't think that's going to happen any time soon! And thank you everyone for your support! I'm excited about being able to contribute to the map like this. Perhaps I should organise an *armchair* mapping party to help trace the roads; anyone here in WA?! - Sam. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Gov access report for September
Damn... I inadvertently sent an internal email to this list. Any help in removing this from archives would be greatly appreciated (I've emailed the list owner). I've never heard that mailman has the ability to redact an email once sent, but if it does, any help on that would also be appreciated. Not having a good day... Thanks Ben ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Energiequelle bei Elektrotankstellen
Am Dienstag 12 Oktober 2010, 23:44:34 schrieb Ulf Lamping: Wieso wird hier lang und breit drüber diskutiert, daß Elektrotankstellen keine Tankstellen sind (z.B. ist ein Akku kein Tank!), und dann kommt wenig später die nächste Träne und kommt mit der gleichen Geschichte wieder an? Das macht echt keinen Spaß. weil das bei OSM so ueblich ist, dass dieselben Themen wieder und wieder aufgewaermt werden. ;-) Das mag einerseits daran liegen dass das Ergebnis nicht immer das Gelbe vom Ei ist und jemand einen besseren Vorschlag einbringt, oder (was in dem meisten Faellen wahrscheinlicher ist) es nicht gut dokumentiert/nicht zu finden ist. Man tankt keinen Strom und Strom ist kein fuel (=Brennstoff). Auch wenn euch das die Werbefuzzies was anderes weismachen wollen. Ohne das ganze wieder aufwaermen zu wollen: Es gibt auch Leute, die anderer Meinung sind, und das sind nicht wenige... Ende des Themas. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
Hallo am 13.10.2010 00:01 schrieb Frederik Ramm: Daher habe ich vorgeschlagen, die Moeglichkeit, eine Relation und all ihre Mitglieder herunterzuladen, fuer API 0.7 zu entfernen (http://wiki.openstreetmap.org/wiki/API_v0.7#Removing_Features). Prima Idee. Hast du auch eine Idee, wie man dann ohne zusätzlichen Aufwand Grenzen und andere Multipoligone herunterläd um sie zu reparieren? Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] rolli-parking mit nummer
Hallo Jan, ich würde die Behindertenparkplätze nicht erfassen, da es sich hier um personenbezogene Parkplätze handelt. Diesen Parkplatz darf nur die Person benutzen, die den Parkausweis mit der Nummer besitzt, die auf dem Schild steht. Daher ist der Behindertenparkplatz für den Rest der Welt uninteressant. Im Übrigen: Nicht nur Rollifahrer sondern auch Blinde können so einen Parkplatz vom Verkehrsamt bekommen. Ciao Holger Jan Tappenbeck schrieb: hi ! es gibt Rolli-Parkplätze die für bestimmte Nummern reserviert sind. Tagt Ihr diese auch und wenn wie ? Gruß Jan :-) ___ 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] Energiequelle bei Elektrotankstellen
Am 12.10.2010 23:55, schrieb C. Brause: Am 12.10.2010 23:44, schrieb Ulf Lamping: Wieso wird hier lang und breit drüber diskutiert, daß Elektrotankstellen keine Tankstellen sind (z.B. ist ein Akku kein Tank!), und dann kommt wenig später die nächste Träne und kommt mit der gleichen Geschichte wieder an? Das macht echt keinen Spaß. Man tankt keinen Strom und Strom ist kein fuel (=Brennstoff). Auch wenn euch das die Werbefuzzies was anderes weismachen wollen. Solange es sich nicht an einer landläufig als Tankstelle bezeichneten Einrichtung zusätzlich angebrachten Steckdose handelt, sowas bitte als amenity=charging_station taggen!!! Gruß, ULFL 1) Ironie Danke für die Träne /Ironie 2) Danke für das amenity charging_station. Das hatte ich gesucht. ICH tagge kein fuel:electricity. LG Christian P.S. dein Post wirkte etwas aggressiv auf mich... Ja, so war auch in etwa mein Gemütszustand wie ich dein Posting gelesen hatte ;-) Sorry, ich hab gerade nochmal: http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dfuel gelesen und dort stand dann tatsächlich fuel:electricity=yes :-( Jetzt vermute ich mal, daß du die Idee daher hattest. Ich hab mal den Versuch unternommen, den aktuellen Stand der Diskussionen dort kurz zu notieren, auf das wir die gleichen Diskussionen nicht in 2 Monaten wieder führen ... Gruß, ULFL P.S: Ich meine mich zu erinnern, das wir fuel:electricity=yes bei normalen Tankstellen beibehalten wollten (eher selten, bis nie?), wäre aber auch nicht beleidigt hier immer amenity=charging_station zu verwenden und fuel:electricity ganz zu streichen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation - die nette Toilette
On Tue, Oct 12, 2010 at 11:23:02PM +0200, Jan Tappenbeck wrote: In Lübeck gibt es einen Zusammenschluss die nette Toilette um Touris das Erleichtern zu ermöglichen. Wen mehr interessiert: http://www.entsorgung.luebeck.de/aktuelles/pressemeldungen/2010/neu_219.html Warum nicht ein Tag nette_toilette=yes oder sowas? Wir haben ja auch nicht alle Einbahnstraßen in einer Relation, oder? Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
On Wed, Oct 13, 2010 at 12:01:07AM +0200, Frederik Ramm wrote: C. Brause wrote: Ich würde gerne wissen, wieso Objekte wie die Stolpersteine in eine Relation gesteckt werden sollen. Das erschließt sich mir nicht. Kann ne kurze Antwort geben (glaub ich aber nicht). Mapper tun das oft, weil sie dadurch - vorausgesetzt, sie kennen die Relations-ID - sehr leicht saemtliche dieser Objekte herunterladen koennen (mit der /relation/xxx/full-Abfrage). Das ist komfortabler, als sich die betr. Objekte anhand der Tags herauszusuchen. Allerdings sind Relationen dafuer eigentlich nicht gedacht (http://wiki.openstreetmap.org/wiki/DE:Relations/Relations_are_not_Categories ). Daher habe ich vorgeschlagen, die Moeglichkeit, eine Relation und all ihre Mitglieder herunterzuladen, fuer API 0.7 zu entfernen (http://wiki.openstreetmap.org/wiki/API_v0.7#Removing_Features). Vielleicht wäre es eine bessere Idee, statt ein nützliches Feature zu entfernen, ein nützlicheres zu schaffen, das dann alle verwenden? Offensichtlich gibt es hier ja eine Anforderung der User. Sie wollen alle Features eines bestimmten Typs leicht finden. Das kann man durch den Trick mit der Relation machen. Oder man benutzt die XAPI. Zumindest solange es nur um einen einzigen Tag geht, macht die XAPI das ja ganz brav. Und bei der XAPI kann ich auch eine Bbox angeben, was man bei dem Weg über die Relation nicht kann. Schwieriger wird es bei geographisch geschachtelten Relationen: Alle Stolpersteine in Bayern oder sowas. Hier ist in der Relation nicht nur der Tag kodiert, sondern eine geographische Information. Und zwar eine, die derzeit sehr schwierig aus der Datenbank zu bekommen ist. Die Alternative ist derzeit, eine eigene Datenbank aufzusetzen mit einem Mirror der Daten, die Grenze von Bayern zusammenzusetzen und dann auszuschneiden. Klar, das das kaum jemand hinbekommt. Vielleicht gibt es noch andere Gründe, warum manche Leute, die Relationen gerne haben. Falls ja, dann sagt Bescheid. Die Gegner der Relationen für diese Zwecke sagen: Informationen in Tags sind leichter zu Verarbeiten und Pflegen als Relationen zu machen, die gerade für Anfänger schwer zu verstehen sind. Wird so eine Relation ausversehen gelöscht, ist das Geschrei groß. Und die Verarbeitung mag zwar einfacher sein für den Gelgenheitsuser, der nur die Relation als XML runterlädt und damit was macht, aber datenbanktechnisch ist es ein Riesenaufwand, weil wir Abhängigkeiten zwischen verschiedenen Objekten haben. Wird z.B. ein Node gelöscht, der in der Relation ist, muss man diese auch immer mit anfassen. Dahinter steckt aber noch ein ganz anderes Problem, verschiedene Ansichten, die so meist nicht formuliert werden, weil beide Seiten sie für selbstverständlich halten und garnicht sehen, dass ihre Weltbilder hier auseinanderlaufen: Der durchschnittliche Mapper, der nur gelegentlich mit den Daten ein bischen was basteln will (z.B. eine Karte aller Stolpersteine in Bayern), erwartet, dass ihm die OSM-Datenbank diese Daten auf einfache Weise rausrückt. Der Hacker oder Informatiker hingegen sieht, dass es sehr aufwändig ist für eine zentrale Datenbank die Informationen in all den Formen zur Verfügung zu stellen, die die verschiedenen Leute brauchen. Er geht also davon aus, dass die zentrale Datenbank nur zum Editieren da ist und alle anderen Formen der Nutzung aus einer Kopie der Datenbank heraus erfolgen, die für die jeweilige spezielle Nutzung optimiert ist. Aber natürlich können die wenigsten eine solche spezielle Datenbank aufsetzen. Der Mapper wird also die pragmatische Lösung wählen (also z.B. Relationen anlegen). Und bei OSM ist die pragmatische Lösung *immer* die richtige Lösung, so ist unser Projekt groß geworden, das gehört eigentlich zu unserer Kultur. Wir wollen keine theoretisch gute Lösung, die aber nicht umsetzbar ist, wir wollen die pragmatische Lösung. Dummerweise ist aber natürlich die Welt komplex und die pragmatischen Lösungen können und werden zu neuen Problemen führen. Aber wenn man die pragmatische Lösung für falsch hält, dann gibt es in unserem Projekt eigentlich nur eine Möglichkeit dem zu entgegnen, nämlich in dem man eine *noch pragmatischere* Lösung schafft, nicht in dem man die pragmatische Lösung verbietet oder verhindert. Wir haben hier also eine Schwierigkeit. Beide Seiten haben vernünftige Argumente, die aus ihrer Sicht Sinn machen. Wir sollten überlegen, was man machen kann, um hier einen Schritt weiter zu kommen, statt immer wieder alte Argumente zu wiederholen. Ein Ansatz wäre sicher, die Funktionen der XAPI bekannter zu machen und weiter auszubauen. Ein anderer wäre es, etwas zu schaffen, was ich mal virtuelle Relationen nenne. Also etwas, das nach außen so aus sieht wie eine Relation, aber nach innen mit Tags funktioniert. Keine Ahnung, wie das genau gehen kann, aber vielleicht hat jemand eine Idee, aus dem Ansatz was zu machen, was allen helfen kann. Ich bin sicher, wenn wir genauer darüber nachdenken, was wir
[Talk-de] libosm
Hi zusammen, ich hab aus dem pbf2osm [1] eine kleine Schnittstelle gebaut, die auch pbf-Support hat. Die momentane Version gibt's hier [2]. Was fehlt ist noch jede Menge Doku :) ... der XML-Teil hinkt etwas hinter dem pbf-Teil hinterher, ist daher mit Vorsicht zu geniessen... Ein paar kleine Beispiele, was man damit machen kann sind auch dabei: - osm2gpx - .osm-XML in's GPX-Format konvertieren - osmpbf2osm - quasi pbf2osm - osm-extract - extrahieren von relations, ways, nodes oder tags(/value), user und/oder bounding box - waydupes- wie der name schon sagt... Im Gegensatz zu Garys waydupes.pl [3] findet dieses hier auch überlappende Teilstücke Feedback, Bugs, ... an mich Hanno [1] http://git.openstreetmap.nl/index.cgi/pbf2osm.git/ [2] http://svn.ankh-morp.org:8080/libosm/release/v0.3/libosm-0.3.tar.gz [3] http://wiki.openstreetmap.org/wiki/Waydupes.pl ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
am Dienstag, 12. Oktober 2010 um 23:58 schrieb C. Brause: Ich würde gerne wissen, wieso Objekte wie die Stolpersteine in eine Relation gesteckt werden sollen. Das erschließt sich mir nicht. Kann ne kurze Antwort geben (glaub ich aber nicht). Also bei den Stolpersteinen schwanke ich auch ein wenig. Man kann immerhin so argumentieren, daß diese Steine ein Gesamtkunstwerk eines Künstlers darstellen. Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation - die nette Toilette
On 13.10.2010 06:57, Jan Tappenbeck wrote: ... und wie sieht die Alternative für die nette Toilettte ??? Gruß Jan :-) http://wiki.openstreetmap.org/wiki/Key:network nur kurze idee... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] rolli-parking mit nummer
danke jan, bin ich echt nicht drauf gekommen. ich kenne rollatoren - diese kleinen wägelchen, die man vor sich herschiebt - aber auf rollstuhl bin ich nicht gekommen. gruss walter - Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll hinein. - Ingo Insterburg -- View this message in context: http://gis.638310.n2.nabble.com/rolli-parking-mit-nummer-tp5628601p5629923.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] Energiequelle bei Elektrotankstellen
Am 12.10.2010 23:55, schrieb C. Brause: 2) Danke für das amenity charging_station. Das hatte ich gesucht. ICH tagge kein fuel:electricity. amenity=charging_station habe ich gerade in die Presets und Mappaint vom JOSM eingebaut. Ab morgen in latest zu finden unter: Vorlagen/Transport/Auto/Charging Station (bzw. wohl Stromtankstelle, wenn es übersetzt worden ist) - bzw. zu sehen auf JOSMs Karte. Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
Hallo, Jochen Topf wrote: Vielleicht wäre es eine bessere Idee, statt ein nützliches Feature zu entfernen, ein nützlicheres zu schaffen, das dann alle verwenden? Die beste Idee waere gewesen, dieses Feature gar nicht erst anzubieten, denn dann haette sich laengst irgendjemand etwas gescheites ausgedacht; solange es die Moeglichkeit des kompletten Relationsdownloads gibt, werden die Leute weiterhin den Weg des geringsten Widerstandes gehen. Daher sehe ich die Entfernung dieses Features als einen sinnvollen ersten Schritt zur vernuenftigen Loesung des Problems; eine vernuenftige Loesung des Problems wird nicht stattfinden, solange es das Feature gibt. Der Mapper wird also die pragmatische Lösung wählen (also z.B. Relationen anlegen). Und bei OSM ist die pragmatische Lösung *immer* die richtige Lösung, so ist unser Projekt groß geworden, das gehört eigentlich zu unserer Kultur. Meiner Ansicht nach war es ein Versehen, dass dieser .../full-Download jemals angeboten wurde. Es gibt sehr viele Dinge, die man als pragmatisch bezeichnen koennte (z.B.: anstatt einen Bot alle highway=residentail in highway=residential umsetzen zu lassen, machen wir doch einfach ein UPDATE-Statement auf der Datenbank), und die der Mapper unter Garantie sofort einsetzen wuerde, wenn man es anboete; wir bieten es aber nicht an. Dem Pragmatismus sind also immer, auch in OSM, Grenzen gesetzt, und ich denke, dass diese Grenze hier korrigiert werden muss. Dummerweise ist aber natürlich die Welt komplex und die pragmatischen Lösungen können und werden zu neuen Problemen führen. Aber wenn man die pragmatische Lösung für falsch hält, dann gibt es in unserem Projekt eigentlich nur eine Möglichkeit dem zu entgegnen, nämlich in dem man eine *noch pragmatischere* Lösung schafft Das ist in dieser Allgemeinheit falsch (s.o. mit den Bots). Ein Ansatz wäre sicher, die Funktionen der XAPI bekannter zu machen und weiter auszubauen. Oder OSM halt einfach naeher zu den Usern bringen - ein kleines Klickibuti-Interface auf Osmosis oben drauf, welche Daten haetten Sie denn heute gern..., dann soll sich das Ding von irgendwo her Bayern oder Luebeck laden und raussuchen, was der User will... Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation - die nette Toilette
Peter Wendorff wrote: http://wiki.openstreetmap.org/wiki/Key:network nur kurze idee... Finde ich persönlich keine gute Idee. network=* provoziert das ; ungemein. nette_toilette=yes wäre schon besser. Wobei ich mich frage, wofür das gut ist. Als bedürftiger ist es mir schließlich egal, welchem Netzwerk die Toilette angehört. Interessant ist ob die Toilette öffentlich zugänglich ist. Letzteres sollte also auf jeden Fall mit eingetragen werden. aighes -- View this message in context: http://gis.638310.n2.nabble.com/Relation-die-nette-Toilette-tp5628639p5629980.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] Relation als Sammelobjekt
Hallo, man sollte m.E. unterscheiden zwischen geordneten Relationen, bei denen es auf die Reihenfolge der Elemente und ggf. auf die Rolle der Elemente ankommt und den sog. Sammelrelationen (oder virtuelle Relationen oder Gruppen), die diese Eigenschaften nicht benötigen! Am 13.10.2010 09:22, schrieb Jochen Topf: Ein anderer wäre es, etwas zu schaffen, was ich mal virtuelle Relationen nenne. Also etwas, das nach außen so aus sieht wie eine Relation, aber nach innen mit Tags funktioniert. Keine Ahnung, wie das genau gehen kann, aber vielleicht hat jemand eine Idee, aus dem Ansatz was zu machen, was allen helfen kann. Also ich könnte mir vorstellen, z.B. nur mit einem hierarchisch gegliederten Tag (group) zu arbeiten, also so wie es mal für is_in vorgeschlagen wurde: Also z.B. so: group=Stolpersteine oder mit geografischer Komponente group=Stolpersteine/DE/Bayern/München Will man alle haben, so kann man sie mit Stolpersteine* selektieren, braucht man nur die in Bayern, dann eben Stolpersteine/DE/Bayern* Alternativ könnte man natürlich auch so arbeiten group=Stolpersteine group:country=DE group:district=Bayern group:city=München finde ich aber nicht so gut, denn dann ist die Gefahr größer, dass Tags fehlen. Eine dritte Variante wäre diese: group:Stolpersteine=yes oder mit Lage group:Stolpersteine=DE/Bayern/München Das wäre eigentlich mein Favorit, denn so ist klar, dass ein Element auch mehreren Gruppen angehören könnte. Der Vorteil der Gruppen (=virtuelle Relationen) liegt auf der Hand: Man muss nur das Tag pflegen und nicht noch eine Relation Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
Am 13.10.2010 00:01, schrieb Frederik Ramm: Allerdings sind Relationen dafuer eigentlich nicht gedacht (http://wiki.openstreetmap.org/wiki/DE:Relations/Relations_are_not_Categories ). Daher habe ich vorgeschlagen, die Moeglichkeit, eine Relation und all ihre Mitglieder herunterzuladen, fuer API 0.7 zu entfernen (http://wiki.openstreetmap.org/wiki/API_v0.7#Removing_Features). Wird lustig wenn hier mal die Überland-Buslinien erfasst werden. Da sind dann Riesendownloads des Gebiets vorprogrammiert, wenn man die Relation nicht mehr einzeln runterladen kann. Will man das? Grüße René ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
Hallo Frederik, meiner Meinung nach ist das der falsche Weg. Bei Routen ist dies bspw. die einzige sinvolle Möglichkeit an die Daten zu kommen. Es ist großer Schwachsinn, dass ich mir für einen einfachen gpx-Track eines Radfernweges Deutschland als Extract herunterladen muss. Besser wäre, wie du schon sagst, ein kleines Klickibunti-Programm als GUI für den API-Aufruf. aighes -- View this message in context: http://gis.638310.n2.nabble.com/Relation-als-Sammelobjekt-tp5628773p5630023.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] Relation - die nette Toilette
On Wed, Oct 13, 2010 at 01:17:39AM -0700, aighes wrote: Peter Wendorff wrote: http://wiki.openstreetmap.org/wiki/Key:network nur kurze idee... Finde ich persönlich keine gute Idee. network=* provoziert das ; ungemein. nette_toilette=yes wäre schon besser. Wobei ich mich frage, wofür das gut ist. Als bedürftiger ist es mir schließlich egal, welchem Netzwerk die Toilette angehört. Interessant ist ob die Toilette öffentlich zugänglich ist. Letzteres sollte also auf jeden Fall mit eingetragen werden. Also wenn eine Toilette nicht öffentlich zugänglich ist, dann sollte man sie vielleicht überhaupt nicht bei OSM eintragen. :-) Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
On Wed, Oct 13, 2010 at 10:19:32AM +0200, Stefan Dettenhofer (StefanDausR) wrote: Am 13.10.2010 09:22, schrieb Jochen Topf: Ein anderer wäre es, etwas zu schaffen, was ich mal virtuelle Relationen nenne. Also etwas, das nach außen so aus sieht wie eine Relation, aber nach innen mit Tags funktioniert. Keine Ahnung, wie das genau gehen kann, aber vielleicht hat jemand eine Idee, aus dem Ansatz was zu machen, was allen helfen kann. Also ich könnte mir vorstellen, z.B. nur mit einem hierarchisch gegliederten Tag (group) zu arbeiten, also so wie es mal für is_in vorgeschlagen wurde: Also z.B. so: group=Stolpersteine oder mit geografischer Komponente group=Stolpersteine/DE/Bayern/München Will man alle haben, so kann man sie mit Stolpersteine* selektieren, braucht man nur die in Bayern, dann eben Stolpersteine/DE/Bayern* Alternativ könnte man natürlich auch so arbeiten group=Stolpersteine group:country=DE group:district=Bayern group:city=München finde ich aber nicht so gut, denn dann ist die Gefahr größer, dass Tags fehlen. Eine dritte Variante wäre diese: group:Stolpersteine=yes oder mit Lage group:Stolpersteine=DE/Bayern/München Das wäre eigentlich mein Favorit, denn so ist klar, dass ein Element auch mehreren Gruppen angehören könnte. Der Vorteil der Gruppen (=virtuelle Relationen) liegt auf der Hand: Man muss nur das Tag pflegen und nicht noch eine Relation Was genau bringen diese Gruppen jetzt gegenüber normalen Tags? Das ist doch jetzt nichts anderes, ob man group:Stolpersteine=DE/Bayern/München tagged oder stolpersteine=yes is_in=DE, Bayer, München oder? Im Gegenteil, hier werden zwei Konzepte vermischt: Nämlich Geographie und Tags. Bei is_in ist wenigstens die Geographie noch getrennt von dem, um was es sich hier handelt. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
On 13.10.2010 07:03, Jan Tappenbeck wrote: Am 13.10.2010 01:06, schrieb Walter Nordmann: C. Brause wrote: ...ich möchte Jans neu gestarteten Thread nicht kapern, daher neu: sorry, ich habs gerade gemacht (das kapern) :( bevor ich deinen beitrag gelesen hab. die darstellung von frederik ist ja wohl klar. ich hatte selber mal solche gruppen-relationen für rettungspunkte, da mir das ganze damals nicht so klar war; aber die sind schon lange draußen. gruss walter das ganze ist eine relativ hartnäckige sache. - Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll hinein. - Ingo Insterburg hi ! aber wie wollt Ihr dann die Möglichkeit haben alle Stolpersteine für einen Bereich oder eines Thema (Stolpersteine in xyz) , was wiederum eine Untermenge (alle Stolpersteine) darstellt. Mann könnte aber Daten über ein Rechteck ermitteln - aber in engen / verschachtelten Siedlungsgebieten ist das nur schwer möglich. Die API läßt keinen Download für eine unregelmäßige Form zu ! Einerseits ist das für API 0.7 vorgeschlagen, auch Polygone als Bounding-box zu erlauben, andererseits ist die API keine direkte Anwendungsschnittstelle. Anwendungsentwickler sollten sich einfach endlich dran gewöhnen, dass ein Postprocessing der API-Antwort der Regelfall ist, und nicht eine Ausnahme für exotische Anwendungen. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation - die nette Toilette
Am 13.10.2010 10:35, schrieb Jochen Topf: Finde ich persönlich keine gute Idee. network=* provoziert das ; ungemein. nette_toilette=yes wäre schon besser. Wobei ich mich frage, wofür das gut ist. Als bedürftiger ist es mir schließlich egal, welchem Netzwerk die Toilette angehört. Interessant ist ob die Toilette öffentlich zugänglich ist. Letzteres sollte also auf jeden Fall mit eingetragen werden. Also wenn eine Toilette nicht öffentlich zugänglich ist, dann sollte man sie vielleicht überhaupt nicht bei OSM eintragen. :-) Bei nette Toilette geht es darum bereits bestehende Toiletten der Gastronomie in öffentliche Toiletten zu wandeln. Ein nette_toilette=yes an ein Restaurant geklebt, wäre daher vielleicht nicht schlecht. Grüße René ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrrad-Access-Karte überarbeitet
Hi Thomas Ineichen, Hallo Steffen, Cool. Ein Wunsch: Ich wuerde surface=cobblestone etwas niedriger einordnen. Beim Kopfsteinpflaster war ich mir auch unsicher, wo ich es einordnen soll; gerade bei Regen gibt es viele solcher Strassen, die dann unangenehm zu befahren sind. Trotzdem gehört es nicht in die 'weisse' Kategorie.. wahrscheinlich ändere ich das zu schwarz gestrichelt o.ä. Kommt eigentlich auf das Kopfsteinpflaster an. Wenn es einigermassen eben ist, dann stimm ich dir zu. Wenn es aber von Stein zu Stein Hoehenunterschiede von 5cm gibt, dann ist's wenigstens weiss, wenn nicht schon rot. Schaust du auch nach smoothness? Oder beruecksichtigst du surface=concrete_plates? Oder surface=paving_stones:20 usw.? Nein und nein. :) :-) @smoothness Ich könnte mir höchstens vorstellen, dass gewisse surface-Werte die schwarzen Linien zu gestrichelten Linien abwerten (ähnlich wie cobblestone) - oder hast Du eine gute Visualisierungs-Idee? Grau? Also Mischfarben zwischen den drei gewaehlten Farben, je nach Auspraegung mal mehr die eine, mal mehr die andere. Macht das aber auch nicht uebersichtlicher, wenn erstmal 100 Abstufungen eingetragen sind. @surface: Ich habe mich vorerst auf die 15 häufigsten Werte beschränkt: http://toolserver.org/~ti/surface.txt BTW: wäre surface=paving_stone, paving_stone:dimension=20x20 nicht besser? Ein neuer Tag? Vielleicht, ich hab's so von der Wiki-Seite: http://wiki.openstreetmap.org/wiki/Key:surface Mit Bezug auf den Semikolon-Thread: Kommst du mit surface=grass;ground und so klar? Nein - ich glaube, das ist hier aber auch nicht so einfach. Wenn du irgendwie XAPI oder Datenbank abfragst mit Select * where surface=key, dann nicht. Wenn du aber irgendwann den vollstaendigen Weg sowieso in die Hand nimmst, dann kannst du s/;.*// anwenden und nur den ersten Eintrag parsen. Hmm, bicycle:hour_on und hour_off fiele mir noch ein, aber das wird wohl etwas zu weit fuehren. DAS hingegen wäre schon wieder einfacher - einfach als String dranpappen. Wäre ein Versuch wert, mit Beschriftungen habe ich bisher noch nie gearbeitet.. Beschriftungen wuerde ich vermeiden wollen. Ich haett's als halbes oder ganzes Verbot gewertet. Wenn du willst: Stricheln mit entsprechender Laenge der Striche und Luecken ;-) Eins fiel mir noch auf: Die bicycle=permissive werden nicht dargestellt. In der Legende steht bicycle=permessive, vielleicht ist der Tippfehler auch im Programmcode? stw -- Zwei kleine UNIX Zeilen, Waren noch geblieben. Die eine war schon reichlich alt Und kam von System Sieben. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] rolli-parking mit nummer
Hi. Rolli-Parkplatz ist der eine Punkt - sollte m.E. eingetragen werden (amenity=parking; parking=surface; surface=asphalt; (o.ä.) capacity:disabled=n) Rolli-Parkplatz für bestimmte Nummern unterscheidet sich aber IMHO nicht von einem normalen Privatparkplatz, abgesehen davon, dass er breiter ist. Oder meinst Du eine Konstruktion, die ich nicht kenne? Gruß Peter On 12.10.2010 23:12, Jan Tappenbeck wrote: hi ! es gibt Rolli-Parkplätze die für bestimmte Nummern reserviert sind. Tagt Ihr diese auch und wenn wie ? Gruß Jan :-) ___ 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] Energiequelle bei Elektrotankstellen
Am 13.10.2010 10:02, schrieb Ulf Lamping: Am 12.10.2010 23:55, schrieb C. Brause: 2) Danke für das amenity charging_station. Das hatte ich gesucht. ICH tagge kein fuel:electricity. amenity=charging_station habe ich gerade in die Presets und Mappaint vom JOSM eingebaut. Ab morgen in latest zu finden unter: Vorlagen/Transport/Auto/Charging Station (bzw. wohl Stromtankstelle, wenn es übersetzt worden ist) - bzw. zu sehen auf JOSMs Karte. Dann wird sich das wohl hoffentlich bald ändern: fuel:electricity=yes gibt es in diesen Kombinationen 61-mal mit amenity=fuel 7-mal mit amenity=parking Die Ladesäule existiert erst 8-mal mit amenity=charging_station ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
Am 13.10.10 10:06, schrieb Frederik Ramm: Hallo, Jochen Topf wrote: Vielleicht wäre es eine bessere Idee, statt ein nützliches Feature zu entfernen, ein nützlicheres zu schaffen, das dann alle verwenden? Die beste Idee waere gewesen, dieses Feature gar nicht erst anzubieten, denn dann haette sich laengst irgendjemand etwas gescheites ausgedacht; solange es die Moeglichkeit des kompletten Relationsdownloads gibt, werden die Leute weiterhin den Weg des geringsten Widerstandes gehen. Dann nenn doch mal funktionierende Alternativen. Xapi lädt keine komplette Relation runter, osmosis kann keine komplette Relation ausschneiden, openlayers braucht zur grafischen Darstellung einer Relation den /full-Download. Um nur mal die wichtigsten Anwendugen zu nennen. Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
Am 13.10.2010 09:22, schrieb Jochen Topf: Ein Ansatz wäre sicher, die Funktionen der XAPI bekannter zu machen und weiter auszubauen. Bzw. mal neu und schön zu implementieren. Wenn es z.B. eine verlässliche und stabile Möglichkeit gäbe (dies bitte als API 0.7 Vorschlag verstehen), die einzelnen Elemente über ihre Tags anzusehen: http://www.openstreetmap.org/browse/tag/historic/stolpersteine für den Tag historic=stolpersteine würde bald keiner mehr die Relation nutzen, da dieser Link - einfacher zu merken / zu identifizieren - immer aktuell - unkaputtbar ist. Leider ist derzeit der Weg über die XAPI aber so unattraktiv, das ihn nur sehr wenige Leute gehen wollen. Nehmt den Leuten nicht die Möglichkeit (-relation-full-requiest) sondern gebt ihnen besser Möglichkeiten, damit sie von den alten ablassen. *) Lg Ein anderer wäre es, etwas zu schaffen, was ich mal virtuelle Relationen nenne. Also etwas, das nach außen so aus sieht wie eine Relation, aber nach innen mit Tags funktioniert. Keine Ahnung, wie das genau gehen kann, aber vielleicht hat jemand eine Idee, aus dem Ansatz was zu machen, was allen helfen kann. Ich bin sicher, wenn wir genauer darüber nachdenken, was wir eigentlich machen bzw. machen wollen, welche Probleme die verschiedenen Leute, versuchen zu lösen, dann werden wir auch einer Lösung näher kommen. Jochen *) Klingt irgendwie wir ein Bibel-Zitat, ists aber nicht ^^ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
ganz einfach - api vergessen und was richtiges verwenden. die api ist 99% tag-bezogen. da muss alles aus tags herausgezogen werden, was irgendwie geht. tags sind dafür da, um zu beschreiben, WAS für ein objekt es ist aber nicht dafür, WO es ist. von einigen ausnahmen abgesehen (is_in, addr:*), die aber nur aus der not heraus geschaffen wurden. die wesentlich bessere information sind diese beiden kleinen werte lat und lon. damit läßt sich das aus osm herauskitzeln, was WIRKLICH interessant/wichtig ist. in dem speziellen fall der stolpersteine benutz man halt die grenzen der interessanten bereiche (stadt, kreis, ...) soweit sie vorhanden sind. und wenn jetzt einer ankommt und meint die sind aber nicht alle drin, dem kann ich nur raten, dagegen was zu tun. gruss walter so, jetzt hol ich mir nen kaffee und bin dann wieder lieb ;) - Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll hinein. - Ingo Insterburg -- View this message in context: http://gis.638310.n2.nabble.com/Relation-als-Sammelobjekt-tp5628773p5630202.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] Relation als Sammelobjekt
Hallo Peter, Polygone als Bounding-box erlauben Das würde vieles erleichtern! Damit könnten viele geografische Bezüge abbgebildet werden. Zusätzlich braucht man aber m.E. noch irgendein ein System für normale relationale / hierarchische Bezüge (Kategorien): z.B. für alle Stolpersteine, alle netten Toiletten, etc) Die Idee von Frederik, für solche Abfragen eine besondere DB anzubieten, in der mit einer GUI simpel alle denkbaren Kombinationen von Werten und Schlüsseln (auch geschachtelt) und kombiniert mit einem Grenz-Polygon abgefragt werden können finde ich genial! Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation - die nette Toilette
nen tag halt, da es eine eigenschaft eines objektes (hier lokal, pub, restaurant, ...) ist. kann jeder verwenden, der nen stadtplan machen will. musst halt nur dafür sorgen, dass er sich rumspricht. - Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll hinein. - Ingo Insterburg -- View this message in context: http://gis.638310.n2.nabble.com/Relation-die-nette-Toilette-tp5628639p5630224.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] Relation - die nette Toilette
René Falk wrote: Bei nette Toilette geht es darum bereits bestehende Toiletten der Gastronomie in öffentliche Toiletten zu wandeln. Ein nette_toilette=yes an ein Restaurant geklebt, wäre daher vielleicht nicht schlecht. wenn ich mich recht entsinne, sind die toiletten in gaststätten prinzipiell öffentlich - da darf jeder rein, der mal muß. sonst bekommt der wirt ärger. allerdings senkt so ein wirklich netter aufkleber, den es bei uns auch gibt, doch erheblich die hemmschwelle. - Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll hinein. - Ingo Insterburg -- View this message in context: http://gis.638310.n2.nabble.com/Relation-die-nette-Toilette-tp5628639p5630239.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] Relation als Sammelobjekt
Am 13. Oktober 2010 11:36 schrieb Markus liste12a4...@gmx.de: Zusätzlich braucht man aber m.E. noch irgendein ein System für normale relationale / hierarchische Bezüge (Kategorien): z.B. für alle Stolpersteine, alle netten Toiletten, etc) das sind keine hierarchischen Bezüge m.E., und das System gibt es von Anfang an, es heisst: Tag (k/v). Ich kann allen raten, die sich wie Jan sowieso Tag und Nacht mit OSM beschäftigen, schaut Euch mal Postgres/Postgis an. Mit der Anleitung von Richard (oder einer anderen je nach System, gibts alles im Wiki) installiert man das Teil in ner viertel Stunde, dann noch mal ein bisschen fürs Einlesen der Daten, und schwuppdiwupp macht man die tollsten Abfragen, anfangs durch Abändern von Beispielen, und irgendwann auch freihand. Wenn man nett fragt schreibt einem vielleicht auch hier auf der Liste jemand ein Beispielquery (im ML-Archiv finden sich AFAIK schon ein paar). Klar, das System ist hochkomplex, aber man muss ja nicht alles bis ins Kleinste verstehen, nur um damit zu arbeiten. Wer Anfragen an die XAPI stellt, weiss im Zweifel auch nicht immer, was da im Hintergrund passiert. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation - die nette Toilette
Hallo, Jochen123 wrote: Also wenn eine Toilette nicht öffentlich zugänglich ist, dann sollte man sie vielleicht überhaupt nicht bei OSM eintragen. :-) Nicht unbedingt, bzw. es hängt davon ab wie man öffentlich zugänglich definiert. Es gibt viele Toiletten, die zwar prinzipiell jeder nutzen könnte, aber bspw. nur Gäste einer Einrichtung legal nutzen dürfen. Bspw. Tankstellen, wo man sich einen Schlüssel holen muss. Das sollte man schon eintragen, aber mit einem entsprechenden access-Tag. Walter Nordmann wrote: wenn ich mich recht entsinne, sind die toiletten in gaststätten prinzipiell öffentlich - da darf jeder rein, der mal muß. sonst bekommt der wirt ärger. allerdings senkt so ein wirklich netter aufkleber, den es bei uns auch gibt, doch erheblich die hemmschwelle. Nein, der Betreiber hat weiterhin Hausrecht und kann den Besuch seiner Einrichtung einschränken. Siehe bspw. Türsteher an Discos. Die Betreiber müssen nur für ihre Gäste eine Toilette vorhalten, wenn sie eine gewisse Geschäftsfläche haben. aighes -- View this message in context: http://gis.638310.n2.nabble.com/Relation-die-nette-Toilette-tp5628639p5630290.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] Energiequelle bei Elektrotankstellen
Am 13.10.2010 01:33, schrieb Michael Kugelmann: Am 12.10.2010 23:55, schrieb C. Brause: P.S. dein Post wirkte etwas aggressiv auf mich... Ach, nur so als Randbemerkung: innerhalb der letzten 4 Wochen gab es auch überhaupt keine Monster-Diskussion zum Theman... Monster-Diskussion hin oder her: Ohne halbwegs deutliches Ergebnis ist die nicht durch. Jetzt ist klar, dass Befürworter der alleinstehenden E-Säulen amenity=charging_station taggen (sollten). Ich war vorher auch für alleinstehend, aber das Tag war mir unklar. Das hat sich dank Ulf aber erledigt. Danke Grüße, Michael. (auch erfreut, dass manche Themen nach ewiger Diskussion regelmäßig wieder auftauchen) PS: man könnte ja mal wieder mit highway = Footway vs. Cycleway vs. Footway anfagen. DR ;-] Könnte man machen, solange noch kein annähernder Konsens gefunden wurde. Nervt zwar, aber WENN dann mal was rauskommt, wäre es echt wichtig. Da gehts nicht vorwärts. Ebenso Spur-Tagging. Aber lassen wird das lieber. Ich hab oben bekommen, was ich wollte ;-) LG Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
Am 13.10.2010 09:28, schrieb Christian H. Bruhn: am Dienstag, 12. Oktober 2010 um 23:58 schrieb C. Brause: Ich würde gerne wissen, wieso Objekte wie die Stolpersteine in eine Relation gesteckt werden sollen. Das erschließt sich mir nicht. Kann ne kurze Antwort geben (glaub ich aber nicht). Also bei den Stolpersteinen schwanke ich auch ein wenig. Man kann immerhin so argumentieren, daß diese Steine ein Gesamtkunstwerk eines Künstlers darstellen. Christian Bei dem Argument reicht ja etwas wie Künstler=Stolpersteinmacher oder sowas. Aber inzwischen wurden ja einige größere Probleme angesprochen. Da gibt es wohl noch mehr. Trotzdem möchte ich, wenn ich einen Stolperstein sehe, den einfach eintragen und nicht noch die irgendwelche Relationen raussuchen und hoffen, dass ich die richtige erwische. Das kann dann zur Not auch der machen, der die auswerten möchte. (Zur Not dann lokal mit runtergeladenen Daten) LG Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
{quote]Wenn man nett fragt schreibt einem
vielleicht auch hier auf der Liste jemand ein Beispielquery (im
ML-Archiv finden sich AFAIK schon ein paar). Klar, das System ist
hochkomplex, aber man muss ja nicht alles bis ins Kleinste verstehen,
nur um damit zu arbeiten. Wer Anfragen an die XAPI stellt, weiss im
Zweifel auch nicht immer, was da im Hintergrund passiert.
hi, es hat zwar keiner gefragt, aber so sieht das aus:
gis= select id
gis- from nodes left join relation_members
gis- on id = member_id
gis- where member_id is null
gis- and nodes.tags @ 'memorial:type=stolperstein'
gis- ;
und dann kommen 27 sst. raus, die NICHT in irgendeiner relation drin sind.
(meine auch)
für die profis: hstore im neuen osmosis simple schema 0.37, - nicht
osm2psql, aber da gehts ähnlich.
gruss
walter
-
Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll
hinein. - Ingo Insterburg
--
View this message in context:
http://gis.638310.n2.nabble.com/Relation-als-Sammelobjekt-tp5628773p5630573.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] Relation als Sammelobjekt
Hi Ich denke auch, die (Re)implementation der XAPI innerhalb der API wäre der richtige Weg. Die XAPI ist unheimlich praktisch - aber meistens überlastet. Wie oft brauche ich z.B. alle Bushaltestellen in gegebener BBox? XAPI - einfach möglich; API - bbox insgesamt laden :( Die Sammelrelationen bieten da nunmal abhilfe, das macht sie praktisch. Ein Verbot, Relationen müssten aber unterschiedliche Rollen für ihre Elemente haben oder so (was dem vorbeugen könnte), halte ich auch für blöd. Die Abfrage nach gemeinsamen Tags dagegen ist IMHO eine sehr gute Möglichkeit. Das ist vermutlich ziemlich aufwändig, auch das ist richtig; aber ich denke, es lohnt sich, das in Angriff zu nehmen. Wenn dann noch propagiert wird, wie weniger anfällig Sammlungen über diese Abfragen für Schäden und Unvollständigkeit sind, sollte sich das auch rumsprechen, dass es sinnvoll verwendbar ist. Gruß Peter On 13.10.2010 11:18, Peter Körner wrote: Am 13.10.2010 09:22, schrieb Jochen Topf: Ein Ansatz wäre sicher, die Funktionen der XAPI bekannter zu machen und weiter auszubauen. Bzw. mal neu und schön zu implementieren. Wenn es z.B. eine verlässliche und stabile Möglichkeit gäbe (dies bitte als API 0.7 Vorschlag verstehen), die einzelnen Elemente über ihre Tags anzusehen: http://www.openstreetmap.org/browse/tag/historic/stolpersteine für den Tag historic=stolpersteine würde bald keiner mehr die Relation nutzen, da dieser Link - einfacher zu merken / zu identifizieren - immer aktuell - unkaputtbar ist. Leider ist derzeit der Weg über die XAPI aber so unattraktiv, das ihn nur sehr wenige Leute gehen wollen. Nehmt den Leuten nicht die Möglichkeit (-relation-full-requiest) sondern gebt ihnen besser Möglichkeiten, damit sie von den alten ablassen. *) Lg Ein anderer wäre es, etwas zu schaffen, was ich mal virtuelle Relationen nenne. Also etwas, das nach außen so aus sieht wie eine Relation, aber nach innen mit Tags funktioniert. Keine Ahnung, wie das genau gehen kann, aber vielleicht hat jemand eine Idee, aus dem Ansatz was zu machen, was allen helfen kann. Ich bin sicher, wenn wir genauer darüber nachdenken, was wir eigentlich machen bzw. machen wollen, welche Probleme die verschiedenen Leute, versuchen zu lösen, dann werden wir auch einer Lösung näher kommen. Jochen *) Klingt irgendwie wir ein Bibel-Zitat, ists aber nicht ^^ ___ 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] rolli-parking mit nummer
Am 13. Oktober 2010 08:39 schrieb Holger s...@der hs69...@web.de: Hallo Jan, ich würde die Behindertenparkplätze nicht erfassen, da es sich hier um personenbezogene Parkplätze handelt. Diesen Parkplatz darf nur die Person benutzen, die den Parkausweis mit der Nummer besitzt, die auf dem Schild steht. Daher ist der Behindertenparkplatz für den Rest der Welt uninteressant. uninteressant fürs Parken schon, es ist AFAIK quasi ein Privatparkplatz, daher m.E. access=private. Wenn Du die Nummer auch eintragen willst (ggf. ein Datenschutzproblem?) dann am einfachsten als description, sonst (wenn man das systematisch vorhat) halt was erfinden. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] rolli-parking mit nummer
On 13.10.2010 14:15, M∡rtin Koppenhoefer wrote: uninteressant fürs Parken schon, es ist AFAIK quasi ein Privatparkplatz, daher m.E. access=private. Wenn Du die Nummer auch eintragen willst (ggf. ein Datenschutzproblem?) dann am einfachsten als description, sonst (wenn man das systematisch vorhat) halt was erfinden. Ich würde die Nummer definitiv nicht eintragen. Die Datenschutz-Problematik sollten wir IMHO nicht unnötig ausreizen. Wen interessiert diese Nummer (legal und sinnvoll), außer dem Inhaber selbst? Natürlich könnte man tolle Jux-Programme machen, die die Parkplätze namentlich anzeigen - aber ist das sinnvoll? Ist es nützlich? Ist nicht die Gefahr groß, dass Datenschützer und entsprechende Kritiker - zu Recht, wie ich finde - hier ein geöffnetes Fass sehen? Den Namen eines Arztes an der Arztpraxis, den Namen eines Rechtsanwalts - das ist interessant für die Suche nach einem entsprechenden Kontakt. Der Inhaber eines Parkplatzes interessiert aber nur, wenn ich einen Anschlag plane oder meinem Chef böswillig den Platz wegnehmen will. Meines Erachtens ist dies also ein personenbezogenes Datum ohne Mehrwert für die OSM, und sollte deshalb tunlichst vermieden werden. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] rolli-parking mit nummer
Am 13.10.2010 10:57, schrieb Peter Wendorff: Hi. Rolli-Parkplatz ist der eine Punkt - sollte m.E. eingetragen werden (amenity=parking; parking=surface; surface=asphalt; (o.ä.) capacity:disabled=n) Rolli-Parkplatz für bestimmte Nummern unterscheidet sich aber IMHO nicht von einem normalen Privatparkplatz, abgesehen davon, dass er breiter ist. Oder meinst Du eine Konstruktion, die ich nicht kenne? Gruß Peter On 12.10.2010 23:12, Jan Tappenbeck wrote: hi ! es gibt Rolli-Parkplätze die für bestimmte Nummern reserviert sind. Tagt Ihr diese auch und wenn wie ? Gruß Jan :-) Hi, was ist parking=surface? LG Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation - die nette Toilette
na ja, war mir halt nicht so sicher - aber die sache mit der disco (ich müsste mal kurz rein ...) leuchtet mir ein. - Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll hinein. - Ingo Insterburg -- View this message in context: http://gis.638310.n2.nabble.com/Relation-die-nette-Toilette-tp5628639p5630824.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] rolli-parking mit nummer
Am 13.10.2010 15:00, schrieb C. Brause: was ist parking=surface? Eine nähere Beschreibung des Parkplatztyps (Parkhaus / Tiefgarage / Normaler Parkplatz auf der Erdoberfläche) http://wiki.openstreetmap.org/wiki/DE:Tag:amenity%3Dparking Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation - die nette Toilette
Am 13. Oktober 2010 08:36 schrieb Jochen Topf joc...@remote.org: Wir haben ja auch nicht alle Einbahnstraßen in einer Relation, oder? gute Idee, angeregt durch diesen Vorschlag bin ich gerade dabei, eine Relation für die Einbahnstraßen (erstmal nur Deutschland, aber wenn das ein Knüller wird, könnte man es auch für die ganze Welt machen) anzulegen. Ein paar Infos zu Einbahnstraßen ist hier zusammengetragen: http://www.gutefrage.net/tag/einbahnstrasse/1 sobald ich fertig bin lade ich das hoch und gebe hier Bescheid, was die einzelnen Relationen-IDs sind. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] rolli-parking mit nummer
Am 13. Oktober 2010 14:47 schrieb Peter Wendorff wendo...@uni-paderborn.de: On 13.10.2010 14:15, M∡rtin Koppenhoefer wrote: Meines Erachtens ist dies also ein personenbezogenes Datum ohne Mehrwert für die OSM, und sollte deshalb tunlichst vermieden werden. M.E. ist ein Datum dann personenbezogen, wenn man es einer Person zuordnen kann. Das ist bei einer Ausweisnummer nur für die Behörden gegeben. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] rolli-parking mit nummer
On 13.10.2010 15:17, M∡rtin Koppenhoefer wrote: Am 13. Oktober 2010 14:47 schrieb Peter Wendorffwendo...@uni-paderborn.de: On 13.10.2010 14:15, M∡rtin Koppenhoefer wrote: Meines Erachtens ist dies also ein personenbezogenes Datum ohne Mehrwert für die OSM, und sollte deshalb tunlichst vermieden werden. M.E. ist ein Datum dann personenbezogen, wenn man es einer Person zuordnen kann. Das ist bei einer Ausweisnummer nur für die Behörden gegeben. Dann spinnen wir uns ein übliches Beispiel zusammen: Der Parkplatz vor einer Arztpraxis hat Kennzeichenspezifische Stellplätze. OSM zeigt den Namen der Ärzte an, die Stellplätze haben Kfz-Kennzeichen. Ich kriege dann vielleicht keine 1:1-Zuordnung, wer welchen Parkplatz und welches Nummernschild hat; ich kann aber schon ganz gut einschränken. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
Am 13. Oktober 2010 13:45 schrieb Peter Wendorff wendo...@uni-paderborn.de: Ich denke auch, die (Re)implementation der XAPI innerhalb der API wäre der richtige Weg. Die XAPI ist unheimlich praktisch - aber meistens überlastet. wenn wir gerade bei wünsch-Dir-was sind: ich würde eine Methode gut finden, um eine lokale db über Diffs synchron zu halten, aber nicht für den kompletten planet, sondern deutlich kleinere Einheiten wie z.B. einzelne Länder / Staaten (was man mit einem normalen bis schwachen PC noch handlen kann). Evtl. könnte man das auch auf lokaler Seite beim Einspielen der Diffs filtern (nur was innerhalb einer gewissen BB oder Polygon ist)? Oder kann man nicht jetzt schon die planet-diffs auf eine Extrakt-Datenbank einspielen und dann was ausserhalb liegt wieder rausschmeissen? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] rolli-parking mit nummer
Am 13. Oktober 2010 16:21 schrieb Peter Wendorff wendo...@uni-paderborn.de: On 13.10.2010 15:17, M∡rtin Koppenhoefer wrote: Am 13. Oktober 2010 14:47 schrieb Peter Wendorffwendo...@uni-paderborn.de: On 13.10.2010 14:15, M∡rtin Koppenhoefer wrote: Meines Erachtens ist dies also ein personenbezogenes Datum ohne Mehrwert für die OSM, und sollte deshalb tunlichst vermieden werden. M.E. ist ein Datum dann personenbezogen, wenn man es einer Person zuordnen kann. Das ist bei einer Ausweisnummer nur für die Behörden gegeben. Dann spinnen wir uns ein übliches Beispiel zusammen: Der Parkplatz vor einer Arztpraxis hat Kennzeichenspezifische Stellplätze. OSM zeigt den Namen der Ärzte an, die Stellplätze haben Kfz-Kennzeichen. Ich kriege dann vielleicht keine 1:1-Zuordnung, wer welchen Parkplatz und welches Nummernschild hat; ich kann aber schon ganz gut einschränken. Die Frage war hier nach Parkplätzen für eingeschränkt Mobile, nicht nach Autonummern, erstere haben gelegentlich ein Zusatzschild der Art nur für den Träger des Ausweises Nr. 543543543 (Wortlaut habe ich gerade nicht parat). Das sind nur dann personenbezogene Daten, wenn man sie auf eine Person bezieht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
Am 13.10.2010 11:50, schrieb M∡rtin Koppenhoefer: Am 13. Oktober 2010 11:36 schrieb Markusliste12a4...@gmx.de: Zusätzlich braucht man aber m.E. noch irgendein ein System für normale relationale / hierarchische Bezüge (Kategorien): z.B. für alle Stolpersteine, alle netten Toiletten, etc) das sind keine hierarchischen Bezüge m.E., und das System gibt es von Anfang an, es heisst: Tag (k/v). Ich kann allen raten, die sich wie Jan sowieso Tag und Nacht mit OSM beschäftigen, schaut Euch mal Postgres/Postgis an. Mit der Anleitung von Richard (oder einer anderen je nach System, gibts alles im Wiki) installiert man das Teil in ner viertel Stunde, dann noch mal ein bisschen fürs Einlesen der Daten, und schwuppdiwupp macht man die tollsten Abfragen, anfangs durch Abändern von Beispielen, und irgendwann auch freihand. Wenn man nett fragt schreibt einem vielleicht auch hier auf der Liste jemand ein Beispielquery (im ML-Archiv finden sich AFAIK schon ein paar). Klar, das System ist hochkomplex, aber man muss ja nicht alles bis ins Kleinste verstehen, nur um damit zu arbeiten. Wer Anfragen an die XAPI stellt, weiss im Zweifel auch nicht immer, was da im Hintergrund passiert. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de HI ! das mag auf den ersten Eindruck richtig sein eine db aufzubauen - aber wenn ich nur mal kleine anwendungen machen will dann ist das mit der api besser. wenn mir z.b. nur ein netbook zur verfügung steht dann wäre das mit der db wohl etwas hoch gegriffen. ich für meinen teil komme so wie es jetzt ist gut aus. für die stolpersteine brauche ich 1 min, für die tankstellen etwas länger. es werden sowieso nur die aktuellen themen (PoiM) und kleinigkeiten täglich upgedatet - die anderen karten 7/14-tägig und dafür baue ich keine db auf. außerdem kann man bei der api auch mal eben von unterwegs ein update fahren. ansonsten siehe ich für karten in größeren ordnungen (garmin) ein osm-file von der geofabrik. nochmal zu (k/v)... wenn sich jeder ein tag für irgendetwas ausedenkt dann ist der wildwuchs nicht weit - bei den tankstellen gab es schon über 250! tags. dann schon lieber relationen. gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation - die nette Toilette
Am 13.10.2010 10:50, schrieb René Falk: Am 13.10.2010 10:35, schrieb Jochen Topf: Finde ich persönlich keine gute Idee. network=* provoziert das ; ungemein. nette_toilette=yes wäre schon besser. Wobei ich mich frage, wofür das gut ist. Als bedürftiger ist es mir schließlich egal, welchem Netzwerk die Toilette angehört. Interessant ist ob die Toilette öffentlich zugänglich ist. Letzteres sollte also auf jeden Fall mit eingetragen werden. Also wenn eine Toilette nicht öffentlich zugänglich ist, dann sollte man sie vielleicht überhaupt nicht bei OSM eintragen. :-) Bei nette Toilette geht es darum bereits bestehende Toiletten der Gastronomie in öffentliche Toiletten zu wandeln. Ein nette_toilette=yes an ein Restaurant geklebt, wäre daher vielleicht nicht schlecht. so sind diese auch gekennzeichnet ! gruß jan :-) Grüße René ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
Am 13.10.2010 17:41, schrieb M∡rtin Koppenhoefer: Am 13. Oktober 2010 17:30 schrieb Jan Tappenbecko...@tappenbeck.net: das mag auf den ersten Eindruck richtig sein eine db aufzubauen - aber wenn ich nur mal kleine anwendungen machen will dann ist das mit der api besser. mag sein, für den Durchschnittsanwender gilt das sicher, für Dich persönlich m.E. eher nicht, wenn ich mir so ansehe, wieviele OSM Projekte Du betreibst. wenn mir z.b. nur ein netbook zur verfügung steht dann wäre das mit der db wohl etwas hoch gegriffen. Ich habe Postgis/Mapnik auf einem Asus 1001p installiert (1,6Ghz Intel Atom, 1GB RAM, 160GB HD, 249,-EUR vor fast nem Jahr). Ist überhaupt kein Problem, habe ganz Italien drin, dauerte vielleicht ne halbe Stunde oder Stunde das Importieren, aber man muss ja nicht ununterbrochen zusehen ;-) hi ! pro import ??? und das ggf. täglich ??? gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] libosm
Hallo Hanno, schön das du das pbf2osm in C geschrieben hast. Habe versucht, das zu übersetzen, aber leider scheiter ich an dem protobuf pfad in dem Makefile. Das Gleiche gilt für libosm. Was für programme benötige ich dafür und welchen pfad muss ich einstellen? Ich benutze Ubuntu Linux. mfg Andre ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
--- Original Nachricht --- Absender: Frederik Ramm Datum: 13.10.2010 00:01 Mapper tun das oft, weil sie dadurch - vorausgesetzt, sie kennen die Relations-ID - sehr leicht saemtliche dieser Objekte herunterladen koennen (mit der /relation/xxx/full-Abfrage). Das ist komfortabler, als sich die betr. Objekte anhand der Tags herauszusuchen. Allerdings sind Relationen dafuer eigentlich nicht gedacht (http://wiki.openstreetmap.org/wiki/DE:Relations/Relations_are_not_Categories ). Daher habe ich vorgeschlagen, die Moeglichkeit, eine Relation und all ihre Mitglieder herunterzuladen, fuer API 0.7 zu entfernen (http://wiki.openstreetmap.org/wiki/API_v0.7#Removing_Features). JOSM nutzt diese Möglichkeit ja auch. Da können die Programmierer, von JOSM, dies ja schonmal versuchen anders umzusetzen. Was ist eigentlich so schlimm an dieser Abfrage-Möglichkeit? Gruß Steffen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] rolli-parking mit nummer
M∡rtin Koppenhoefer wrote: Die Frage war hier nach Parkplätzen für eingeschränkt Mobile, nicht nach Autonummern, erstere haben gelegentlich ein Zusatzschild der Art nur für den Träger des Ausweises Nr. 543543543 (Wortlaut habe ich gerade nicht parat). Das sind nur dann personenbezogene Daten, wenn man sie auf eine Person bezieht. ich frage mich, warum sollte die nummer in osm rein? ich sehe absolut keinen grund dafür. ok, die info, dass es sich um einen RESERVIERTEN platz handelt hier parkplatz aber nicht für dich !!! ist ok, aber wofür die kennzeichnung? gruss walter - Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll hinein. - Ingo Insterburg -- View this message in context: http://gis.638310.n2.nabble.com/rolli-parking-mit-nummer-tp5628601p5632515.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] Relation - die nette Toilette
Am 13.10.2010 10:17, schrieb aighes: nette_toilette=yes wäre schon besser. bite nicht: nicht für jeden Eigennamen eine eigene Tag-Hierarchie, sonst haben wir bald einen unüberschaubaren Wildwuchs. Wenn dann von mir aus Operator=Nette Toilette oder so etwas. Aber bitte nicht Eigennamen auf der Key-Seite, sondern nur auf der Wert-Seite! Grüße, Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation - die nette Toilette
Am 13.10.2010 15:14, schrieb M∡rtin Koppenhoefer: gute Idee, angeregt durch diesen Vorschlag bin ich gerade dabei, eine Relation für die Einbahnstraßen (erstmal nur Deutschland, aber wenn das ein Knüller wird, könnte man es auch für die ganze Welt machen) anzulegen. Dazu eine Ziztat su dem Tread: am 12.10.2010 23:50, schrieb Ulf Lamping: Bitte folgendes lesen: http://wiki.openstreetmap.org/wiki/DE:Relations/Relations_are_not_Categories ... und von dieser Idee Abstand nehmen. +1 Grüße, Michael. (Kopfschütteln, oder wo steht der Smiley?) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TüV Reinland Breitbandatlas basiert au f OSM-Daten
derandi unnoetige_ma...@gmx.de wrote: http://www.zukunft-breitband.de/BBA/Navigation/Breitbandatlas/breitbandsuche.html Interessant ist das ein Ministerium des Bundes die Daten nutzt. ;) Immerhin haben wir eine Person in der Community, die dort tätig ist und auf dem letzten bundesdeutschen OSM Treffen im Rahmen der Fossgis 2010 einen Vortrag gehalten hat. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
M∡rtin Koppenhoefer wrote: schwachen PC noch handlen kann). Evtl. könnte man das auch auf lokaler Seite beim Einspielen der Diffs filtern (nur was innerhalb einer gewissen BB oder Polygon ist)? Oder kann man nicht jetzt schon die planet-diffs auf eine Extrakt-Datenbank einspielen und dann was ausserhalb liegt wieder rausschmeissen? ich hab früher einfach ne bbox in das osm2pgsql-script eingebaut. dort wo osmosis den job macht. dennoch kamen viele daten in die db. bei der - für mich besseren - osmosis/simple geht das ja nicht, da osmosos das mit diff-files nicht zuläßt. da wird die db bald riesig, auch wenn man nur z.b. mit castrop-rauxel angefangen hat. irgendwann sind die osterinseln auch drin gewesen. inzwischen schmeiss ich sehr viele daten einfach raus, die zu weit draussen liegen. zuletzt mussten 28 mio nodes dran glauben. das verfahren für osm2pgsql ist im ansatz hier beschrieben: http://wiki.openstreetmap.org/wiki/User:Stephankn/knowledgebase ich musste das aber erheblich an die osmosis/simple 0.37 anpassen, weil die datenstruktur total anders ist. das prinzip ist bei beiden ganz einfach: schritt 1: alle nodes raus, die weg sollen schritt 2: alle ways raus, die keine nodes (mehr) haben schritt 3: alle relationen raus, die (jetzt) leer sind (keine nodes UND keine ways). dazu hab ich mir dann noch ne relativ große bbox definiert, damit ich in den grenzgebieten nichts verliere das ganze per chron: a) import des diffs b) cleanup gruss walter - Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll hinein. - Ingo Insterburg -- View this message in context: http://gis.638310.n2.nabble.com/Relation-als-Sammelobjekt-tp5628773p5632642.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] rolli-parking mit nummer
Hallo Bitte beachtet, dass das aktuelle Konzept von 'Parkplatz' ein Parkplatz-Areal meint. Daher auch der optionale Zusatz-Tag capacity=number für die Anzahl der verfügbaren Parkplätze eines Areals (vgl. http://wiki.openstreetmap.org/wiki/DE:Tag:amenity%3Dparking). Ich meine, dass persönliche Parkplätze (ob Areal oder Einzel) nicht interessant sind für OSM, ähnlich wie private. Auf jeden Fall kann m.E. eine solche Nummer nur an Einzelparkplätze hinzugefügt werden (auch wenn das amenity=parking als Node zulassen würde). Einzelparkplätze sollten *nicht* mit amenity=parking getaggt werden. Der aktuelle Vorschlag ist parking_space=normal|woman|disabled|yes (vgl. die Diskussion hier: http://www.mail-archive.com/talk-de@openstreetmap.org/msg75425.html !). LG, S. Am 13. Oktober 2010 22:11 schrieb Walter Nordmann walter.nordm...@web.de: M∡rtin Koppenhoefer wrote: Die Frage war hier nach Parkplätzen für eingeschränkt Mobile, nicht nach Autonummern, erstere haben gelegentlich ein Zusatzschild der Art nur für den Träger des Ausweises Nr. 543543543 (Wortlaut habe ich gerade nicht parat). Das sind nur dann personenbezogene Daten, wenn man sie auf eine Person bezieht. ich frage mich, warum sollte die nummer in osm rein? ich sehe absolut keinen grund dafür. ok, die info, dass es sich um einen RESERVIERTEN platz handelt hier parkplatz aber nicht für dich !!! ist ok, aber wofür die kennzeichnung? gruss walter - Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll hinein. - Ingo Insterburg -- View this message in context: http://gis.638310.n2.nabble.com/rolli-parking-mit-nummer-tp5628601p5632515.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] Relation - die nette Toilette
Hallo, Am Mittwoch 13 Oktober 2010 15:14:46 schrieb M∡rtin Koppenhoefer: Am 13. Oktober 2010 08:36 schrieb Jochen Topf joc...@remote.org: Wir haben ja auch nicht alle Einbahnstraßen in einer Relation, oder? gute Idee, angeregt durch diesen Vorschlag bin ich gerade dabei, eine Relation für die Einbahnstraßen (erstmal nur Deutschland, aber wenn das ein Knüller wird, könnte man es auch für die ganze Welt machen) anzulegen. Ein paar Infos zu Einbahnstraßen ist hier zusammengetragen: http://www.gutefrage.net/tag/einbahnstrasse/1 sobald ich fertig bin lade ich das hoch und gebe hier Bescheid, was die einzelnen Relationen-IDs sind. Klasse Idee! Ich werde wohl eine Relation aller grünen Ampeln machen. Endlich freie Fahrt! Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation - die nette Toilette
Wolfgang schrieb: Hallo, Am Mittwoch 13 Oktober 2010 15:14:46 schrieb M∡rtin Koppenhoefer: Am 13. Oktober 2010 08:36 schrieb Jochen Topf joc...@remote.org: Wir haben ja auch nicht alle Einbahnstraßen in einer Relation, oder? gute Idee, angeregt durch diesen Vorschlag bin ich gerade dabei, eine Relation für die Einbahnstraßen (erstmal nur Deutschland, aber wenn das ein Knüller wird, könnte man es auch für die ganze Welt machen) anzulegen. Klasse Idee! Ich werde wohl eine Relation aller grünen Ampeln machen. Endlich freie Fahrt! Warum nicht gleich 'ne Relation aller Nodes, Ways und Relationen? Da können wir uns dann endlich diese großen planet-files sparen! ;-) Grüße, Michi signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation als Sammelobjekt
Am 13.10.2010 21:37, schrieb Steffen: Daher habe ich vorgeschlagen, die Moeglichkeit, eine Relation und all ihre Mitglieder herunterzuladen, fuer API 0.7 zu entfernen (http://wiki.openstreetmap.org/wiki/API_v0.7#Removing_Features). [...] Was ist eigentlich so schlimm an dieser Abfrage-Möglichkeit? Das Problem ist wohl nicht die Abfragemöglichkeit an sich, sondern dass die API hier momentan Relationen gegenüber anderen Möglichkeiten der Gruppierung bevorzugt - dass es also für Relations-Mitglieder eine Abfragemöglichkeit direkt in der API gibt, aber für z.B. Objekte mit gleichen Tags oder Objekte innerhalb einer Grenze derzeit keine ebenso komfortable Anfrage existiert. Hätten Mapper die Disziplin, Relationen trotzdem nur dort zu verwenden, wo sie angebracht sind, wäre das ja kein Problem. Aber diese technische Wettbewerbsverzerrung wird eben zunehmend als Anlass genommen, Dinge, für die etwa Tags oder Grenzen eigentlich die bessere Lösung wären, stattdessen oder zusätzlich mit Relationen einzutragen. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation - die nette Toilette
Am 14.10.2010 00:24, schrieb Michael Bemmerl: Wolfgang schrieb: Ich werde wohl eine Relation aller grünen Ampeln machen. Endlich freie Fahrt! Warum nicht gleich 'ne Relation aller Nodes, Ways und Relationen? Da können wir uns dann endlich diese großen planet-files sparen! ;-) Oh, prima. Ich mache eine Relation aller Relationen, die sich nicht selbst enthalten. ;-) Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrrad-Access-Karte überarbeitet
Hallo Heiko, am Dienstag, 12. Oktober 2010 um 21:48 schrieben Sie: Am 11.10.2010 12:01, schrieb Thomas Ineichen: Weiss für verfestigte/bearbeitete Oberflächen Mir fällt gerade auf, dass weiß etwas suboptimal kommt ... Gelb vielleicht besser? Ansonsten hübsch ;-) Die weissen Striche ohne Access-Umrandung sind eigentlich ungewolltes Nebenprodukt, daher müssen sie gar nicht sichtbar sein.. ;-) Ginge noch Osmarender als weitere wählbare Hintergrundkarte? In den besseren Zoomstufen sind Feld-/Rad-/Gehwege darin nicht nur dünne Striche, sondern breit, so dass man evtl. den Basisweg besser erkennen könnte. Ist integriert. Zusätzlich kann man auch meinen Layer aufhellen (20%), so dass die dahinterliegende Karte besser durchscheint. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation - die nette Toilette
Am 13.10.2010 15:14, schrieb M∡rtin Koppenhoefer: Ein paar Infos zu Einbahnstraßen ist hier zusammengetragen: Ich hoffe eigentlich immer anständig, dass Toiletten Einbahnstraßen (für die Fäkalien) sind. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation - die nette Toilette
Am 13.10.2010 18:07, schrieb Jan Tappenbeck: Bei nette Toilette geht es darum bereits bestehende Toiletten der Gastronomie in öffentliche Toiletten zu wandeln. so sind diese auch gekennzeichnet ! Interessanter wird hier das Öffnungszeiten-Mapping. Denn was hilft eine angeblich öffentliche Toilette, wenn das umgebende Geschäft z.B. Montag Ruhetag hat oder oder in der zweiten Januarwoche Betriebsferien macht. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Ampel-Tagging (Re: Relation - die nette Toilette)
Am 14.10.2010 00:09, schrieb Wolfgang: Ich werde wohl eine Relation aller grünen Ampeln machen. Endlich freie Fahrt! Welches Tagging-Schema gilt denn für die Lackierung der Masten und Farbe von Auslegerarm, Signalgeberkammer, Sonnenschute? Dazu gibt's dann noch die Kontrastblenden in schwarz mit weißem Rand und weiss mit schwarzem Rand, eckig, rund etc.pp. Die von Dir angesprochenen grünen Ampeln kenne ich jedoch nur aus Italien: http://www.info-lsa.de/images/Ampelbilder/EUR/Italien_Rom_FGrt.jpg -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrrad-Access-Karte überarbeitet
Hallo Steffen, Kommt eigentlich auf das Kopfsteinpflaster an. Wenn es einigermassen eben ist, dann stimm ich dir zu. Wenn es aber von Stein zu Stein Hoehenunterschiede von 5cm gibt, dann ist's wenigstens weiss, wenn nicht schon rot. Wahrscheinlich bin ich hier in der Schweiz einfach zu verwöhnt. Leider haben von den 67'143 cobblestone-highways nur gerade 1'444 eine Smoothness-Angabe: http://toolserver.org/~ti/cobblestone.txt Ich bastle gerade an einer anderen Anwendung, bei der Oberflächen wichtiger sind, ev. fallen von dort ein paar Code-Schnipsel ab. Bis dahin werde ich cobblestone auf schwarz/weiss ändern. Grau? Also Mischfarben zwischen den drei gewaehlten Farben, je nach Auspraegung mal mehr die eine, mal mehr die andere. Macht das aber auch nicht uebersichtlicher, wenn erstmal 100 Abstufungen eingetragen sind. Und dann gibt's dafür die Diskussionen, ob ein gravel-Weg mit good heller oder dunkler sein sollte als ein compacted-Weg mit inter- mediate :- SELECT smoothness, surface, count WHERE tags ? 'surface' GROUP BY smoothness, surface http://toolserver.org/~ti/smoothness_surface.txt Wenn du irgendwie XAPI oder Datenbank abfragst mit Select * where surface=key, dann nicht. Wenn du aber irgendwann den vollstaendigen Weg sowieso in die Hand nimmst, dann kannst du s/;.*// anwenden und nur den ersten Eintrag parsen. Wenn, dann möchte ich aber den 'schlechtesten' der Tags erkennen, um den Weg entsprechend hell einzufärben. Soviel Qualität muss sein. ;-) Beschriftungen wuerde ich vermeiden wollen. Ich haett's als halbes oder ganzes Verbot gewertet. Wenn du willst: Stricheln mit entsprechender Laenge der Striche und Luecken ;-) Wir hatten vorgestern am Zürcher Stammtisch eine Präsentation/Diskus- sion mit dem Chef von OCAD[1], einer Kartographie-Software - Fazit: In schönen und ansprechenden Karten steckt verdammt viel Arbeit.. Eins fiel mir noch auf: Die bicycle=permissive werden nicht dargestellt. In der Legende steht bicycle=permessive, vielleicht ist der Tippfehler auch im Programmcode? Das schreibe ich ständig falsch, obwohl ich eigentlich weiss, dass es von 'permission' kommt.. :-/ Der Stil ist aktualisiert und stellt jetzt auch Motorfahrzeug-Verbote in hellblau dar. Die Caching-Strategie von Tirex sorgt aber offenbar dafür, dass die Kacheln nicht sofort neu gerendert werden.. Gruss, Thomas [1] http://ocad.ch/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation - die nette Toilette -ver... mich selber
Am 14.10.2010 00:47, schrieb Tobias Knerr: Am 14.10.2010 00:24, schrieb Michael Bemmerl: Wolfgang schrieb: Ich werde wohl eine Relation aller grünen Ampeln machen. Endlich freie Fahrt! Warum nicht gleich 'ne Relation aller Nodes, Ways und Relationen? Da können wir uns dann endlich diese großen planet-files sparen! ;-) Oh, prima. Ich mache eine Relation aller Relationen, die sich nicht selbst enthalten. ;-) Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ich wußte nicht das mapper so humorvoll und einfallsreich sind ...! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] utenti che hanno confermato la nuova licenza
Il 12 ottobre 2010 20:51, Paolo Molaro lu...@oddwiz.org ha scritto: è stato valutato anche questo: ricominciare da zero con una db vuota (come proponi te) ed è stato bocciato l'idea. Avere un db misto purtroppo è impossibile perché la cc-by-sa 2.0 richiede che i nuovi dati anche diventano cc-by-sa. La cc-by-sa non è compatibile con la odbl. La cc-by-sa e' perfettamente compatibile con il dual licensing. Non sono un avvocato e non mi intendo di license, ma non è solo la cc-by-sa che deve essere compatibile con il dual licensing - dovrebbe esserlo anche la ODbL, e dovrebbero essere compatibili tra di loro. Anche il buddismo non ti impedisce di seguire un'altra religione, ma il cristianesimo sì, quindi non puoi essere buddista e cattolico. lupus Ciao, Simone ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Obblighi con la OSBL
Cosa cambierà dal punto di vista pratico? Con la 'vecchia' si doveva scrivere ad esempio (C) Openstreetmap and contributors CC-BY-SA, con la nuova occorrerà una nuova frase o qualcosa di diverso? Me lo chiedevo mentre preparavo le slides per il Linux Day, rimarrà come unico obbligo quello di citare la fonte dei dati? Alessandro ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
