Re: [Talk-hr] banka POI
On Fri, Nov 06, 2009 at 12:56:40PM +0100, Marko Dimjasevic wrote: On Srijeda, 04. Studeni 2009. 22:42:55 nixa wrote: Privredna banka Zagreb Privredna banka Zagreb d.d. PBZ PBZ d.d Obzirom da mnogo objekata nosi/će nositi ime PBZ-a, definitivno treba odabrati nešto što je što manje podložno promjenama, a što je opet razumljivo. Zbog toga predlažem da se ne koristi oznaka kakvog je tipa društvo (ovdje konkretno d.d.) jer se možda kojim slučajem to promijeni. A moze se promijeniti i naziv, evo ZABA je za dlaku izbjegla da postane UniCredit (ali su joj prepoznatljiv logo svejedno zamijenili) Predlažem da se koristi Privredna banka zagreb radi izbjegavanja poistovjećivanja s drugim stvarima koje nose/će nositi kraticu PBZ. Također, kod Zagrebačke banke mi se čini bolje koristiti upravo taj puni naziv, a ne ZABA. Dakle - bez oznake tipa društva i sa punim nazivom. Ja sam pak suprotnog misljenja. Iako generalno podrzavam da ne mapiramo radi renderera, mislim da ih ipak treba uzeti u obzir prilikom takvih odlucivanja. Sa kraticama (RBA, PBZ, ZABA) to izgleda prilicno dobro na samoj karti, a i svima je jasno o cemu se radi (slikica bankomata kraj koje pise PBZ ne ostavlja mjesta za zabunu). Sa dugim imenima pak, pogotovo na mobilnim uredjajima, stvar je katastrofa, naziv bankomata bi pojeo pol ekrana :) I ne daj boze da ih bude vise od jednog odjednom na karti... Tako da predlazem da se koriste samo kratice za operator tag, dakle RBA, PBZ i sl. (i bez name taga za bankomate). Ukoliko postoji mogucnost zabune (sto ne vidim kao problem, ali ostavljam mogucnost takvog neceg u buducnosti), mislim da bi puni naziv (npr. Privredna banka Zagreb tada trebalo staviti u description tag, a ne u operator (gdje bih ostavio u narodu prihvacene kratice) -- Opinions above are GNU-copylefted. ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Gradovi u HR (place=town)
On Thu, Nov 05, 2009 at 08:30:39PM +0100, Marjan Vrban wrote: Upravo sam završio izmjene na karti sa svim gradovima u HR (place=town) i izmjenio one što to nisu u (place=village.) http://narodne-novine.nn.hr/clanci/sluzbeni/127788.html Jeli se članstvo slaže s time? naravno, odlicno! -- Opinions above are GNU-copylefted. ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] banka POI
Matija Nalis wrote: Tako da predlazem da se koriste samo kratice za operator tag, dakle RBA, PBZ i sl. (i bez name taga za bankomate). Ja se slazem s ovim, no problem je onda s bankama za koje ne postoji kratice :) A da od bankomata radimo neke relacije? Jel to izvedivo? Da su svi bankomati od PBZ-a grupirani u neku PBZ relaciju pa da imaju zajednicki operator? Ovdje se nalazi popis svih banaka u HR. http://www.hnb.hr/supervizija/liste/hlista_banaka.htm ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] banka POI
On Sat, 07 Nov 2009 12:45:38 +0100, nixa wrote: Matija Nalis wrote: Tako da predlazem da se koriste samo kratice za operator tag, dakle RBA, PBZ i sl. (i bez name taga za bankomate). Ja se slazem s ovim, no problem je onda s bankama za koje ne postoji kratice :) A da od bankomata radimo neke relacije? Jel to izvedivo? Da su svi bankomati od PBZ-a grupirani u neku PBZ relaciju pa da imaju zajednicki operator? Ovdje se nalazi popis svih banaka u HR. http://www.hnb.hr/supervizija/liste/hlista_banaka.htm Ja se definitivno ne slažem s kraticama, za oznaku operator= moralo bi se navesti puno ime, jer to može služiti npr. u nekoj aplikaciji, izlistaj sve podružnice, poslovnice i bankomate Privredne banke Zagreb. A za name= IMHO bi mogli ići i skraćeno, a možda dodati podružnica br. A poželjno je i ukucati radno vrijeme i recimo telefon I naravno stavit sve to (poslovnice, bankomate itd.) u relaciju Privredna banka Zagreb, a recimo i radi lakših izmjena kompletne banke tj. operatora. Isto tako može i za benzinske ; primjer 2: Primjer 1: http://www.openstreetmap.org/browse/node/528993664 Točka: Privredna banka Zagreb (528993664) 528993663 | 528993665 Uređeno:Ned Lis 11 18:39:18 GMT 2009 Uredio: mvrban Verzija:1 U changesetu: 2817831 Komentar: Osijek traffic lights + zebra Oznake: amenity = bank atm = yes name = Privredna banka Zagreb opening_hours = Mo-Fr 08:00-19:00 operator = Privredna banka Zagreb d.d. Koordinate: 45,556112, 18,6829581 Primjer 2: http://www.openstreetmap.org/browse/node/332069186 Točka: OMV (332069186) 332069185 | 332069187 Uređeno:Pet Lis 16 19:54:53 GMT 2009 Uredio: mvrban Verzija:4 U changesetu: 2867761 Komentar: Osijek - Trgovine i benze, adrese i radno vrijeme Oznake: addr:city = Osijek addr:country = HR addr:housenumber = bb addr:postcode = 31000 addr:street = Svetog Leopolda Bogdana Mandića amenity = fuel name = OMV opening_hours = 24/7 operator = OMV phone = +385(31)298193 Koordinate: 45,5506629, 18,6680717 ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Gradovi u HR (place=town)
to je ok... 2009/11/7 Matija Nalis mnalis-openstreetmapl...@voyager.hr: On Thu, Nov 05, 2009 at 08:30:39PM +0100, Marjan Vrban wrote: Upravo sam završio izmjene na karti sa svim gradovima u HR (place=town) i izmjenio one što to nisu u (place=village.) http://narodne-novine.nn.hr/clanci/sluzbeni/127788.html Jeli se članstvo slaže s time? naravno, odlicno! -- Opinions above are GNU-copylefted. ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
Re: [OSM-talk] Why do you use Google Maps instead of OSM? Because of buildings...
On Fri, Nov 6, 2009 at 11:52 PM, Andrew Errington a.erring...@lancaster.ac.uk wrote: What the web person *should* have done is looked at OSM in their new location and fixed the underlying data (if it was wrong or incomplete) or made their own map based on the data, but omitting the features they didn't like. The web person in question probably has a lot of tasks on his hands. It takes 5 minutes to embed a Google Maps map instead of an OSM map but tracing a 10-block radius as in this case is going to take half a day at best, assuming quality aerial imagery. Likewise setting up your own rendering takes half a day at best if you're not already familiar with the rendering tools involved. Of course, we all know this. Yes, we know that everyone could probably use OSM maps for their business website if they spent a week surveying their surrounding area / creating custom renderings. But that's not very helpful when they can just embed Google instantly and get the same results. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM Logo Competition
On Sat, Nov 7, 2009 at 06:56, SteveC st...@asklater.com wrote: The OSMF recently launched a new mediawiki powered site at http://www.osmfoundationorg/ with a basic logo. ouch...typo: http://www.osmfoundation.org/ -- -S ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Why do you use Google Maps instead of OSM? Because of buildings...
Liz wrote: On Sat, 7 Nov 2009, Dave F. wrote: I asked an NGO based in London why they use Google Maps instead of OSM on their 'contact us' page To all the people who posted earlier than me: Yes, you all stated how it could be done how to correct it, but... You haven't answered the problem of why they went with G. instead of OSM. in the first place. some see problems and some see opportunities To take an opportunity / find a solution, you first have to be aware of acknowledge a problem. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM Logo Competition
SteveC wrote: We'd love to have a logo that better reflects the foundation... For confirmation, is this a logo just for the foundation, or for the wider project? Cheers Dave F. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Why do you use Google Maps instead of OSM? Because of buildings...
On Sat, Nov 7, 2009 at 4:00 AM, Ævar Arnfjörð Bjarmason ava...@gmail.com wrote: Yes, we know that everyone could probably use OSM maps for their business website if they spent a week surveying their surrounding area / creating custom renderings. But that's not very helpful when they can just embed Google instantly and get the same results. If they spent a week surveying their surrounding area they could probably get much better results than Google. If what they want is exactly what Google provides, there's really no way to compete against that. Anthony ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Potlatch, dual carriageways, and a broken changeset
On Nov 6, 2009, at 6:38 PM, Russ Nelson wrote: Michal Migurski writes: instead make sure that multi-level undo is completely bulletproof. To make life more interesting, OSM editing goes on concurrently, and yet nearly everyone who is editing is editing a chunk locally. So OSM is episodically being synched with chunks of data we call a changeset, but which also includes the concept of an edit conflict meaning that two chunks have been edited at the same time. Simultaneous editing of geodata is currently not a solved problem. Even less solved is the concept of multi-level undo, much less single-level undo. Within an editing session? Sure. Within your chunk of data? Sure. But not outside that. I think this further underscores the difference between save mode and edit mode. Save mode is more like traditional desktop document editing, and the undo history need only be consistent with what you're doing in your own session. In this case, it should be possible to ditch the locked ways and instead make sure that the local document is fully self-consistent and undo-able. For live mode, clearly an undo feature would introduce more trouble than it's worth, for everyone involved in editing a particular area. There the presence of locked or ghosted ways as in the current Potlatch does make sense, but I do think the terminology and visual presentation could be tweaked a bit. I know what you mean about this not being a solved problem, and given how much time I spend with SVN, Git, etc. I'm pretty aware of how hard it can be to merge concurrent edits on the same resource. -mike. michal migurski- m...@stamen.com 415.558.1610 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal -Voting - (man_made=mineshaft)
Lesi writes: I do not know which discussion you mean? According to the wiki voting is still neccessary to approve a new feature. What negative result do you fear would occur if somebody used[1] an unapproved feature? [1] That is, they tagged something as documented in the wiki, even if the documentation is to be found in Proposed Features? I'm not a big fan of chaotic mapping, where people apply tags randomly without understanding how they're documented in the wiki, or apply tags without documenting their meaning in the wiki. IMHO, everything underneath Proposed_features should be moved into the real wiki (e.g. http://wiki.openstreetmap.org/wiki/Proposed_features/Key:stop should be moved to http://wiki.openstreetmap.org/wiki/Key:stop) and the feature should be labelled with 1) its current level of usage and 2) a measure of its controversiality (red / yellow / green). That would make it easier for OSM editors to point people to documentation. -- --my blog is athttp://blog.russnelson.com Crynwr supports open source software 521 Pleasant Valley Rd. | +1 315-323-1241 Potsdam, NY 13676-3213 | Sheepdog ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Why do you use Google Maps instead of OSM? Because of buildings...
On 7 Nov 2009, at 13:32, Anthony wrote: On Sat, Nov 7, 2009 at 4:00 AM, Ævar Arnfjörð Bjarmason ava...@gmail.com wrote: Yes, we know that everyone could probably use OSM maps for their business website if they spent a week surveying their surrounding area / creating custom renderings. But that's not very helpful when they can just embed Google instantly and get the same results. If they spent a week surveying their surrounding area they could probably get much better results than Google. If what they want is exactly what Google provides, there's really no way to compete against that. Maybe we need some method for companies/organisations to be able to say that an area isn't surveyed to a level they want and that they would like a particular area to be surveyed to a higher degree for a specific purpose. OpenStreetBugs is more for point errors, rather than larger problems. Maybe OSB needs to be exposed more? Shaun ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Why do you use Google Maps instead of OSM? Because of buildings...
2009/11/7 Shaun McDonald sh...@shaunmcdonald.me.uk Maybe we need some method for companies/organisations to be able to say that an area isn't surveyed to a level they want and that they would like a particular area to be surveyed to a higher degree for a specific purpose. OpenStreetBugs is more for point errors, rather than larger problems. Maybe OSB needs to be exposed more? I think Mappa Mercia, whose template I coped for the Sutton Green Map, is pretty instructive here. The menu along the top very clearly exposes OSB, provides a fairly plain English guide to contributing, and helps people understand how they can use the map: http://mappa-mercia.org/ I don't know what's happening to the oft-floated redesign, but this thread does again show up some basic shortcomings. Regards, Tom -- http://tom.acrewoods.net http://twitter.com/tom_chance ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Why do you use Google Maps instead of OSM? Because of buildings...
On Sat, Nov 7, 2009 at 1:08 PM, Shaun McDonald sh...@shaunmcdonald.me.uk wrote: On 7 Nov 2009, at 13:32, Anthony wrote: On Sat, Nov 7, 2009 at 4:00 AM, Ævar Arnfjörð Bjarmason ava...@gmail.com wrote: Yes, we know that everyone could probably use OSM maps for their business website if they spent a week surveying their surrounding area / creating custom renderings. But that's not very helpful when they can just embed Google instantly and get the same results. If they spent a week surveying their surrounding area they could probably get much better results than Google. If what they want is exactly what Google provides, there's really no way to compete against that. Maybe we need some method for companies/organisations to be able to say that an area isn't surveyed to a level they want and that they would like a particular area to be surveyed to a higher degree for a specific purpose. Along with a donation of time and/or money and/or data and/or resources for the purpose of fulfilling that request :). I hope that unlike Wikipedia, OSM allows and encourages such paid editing. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal -Voting- (man_made=mineshaft)
What negative result do you fear would occur if somebody used[1] an unapproved feature? [1] That is, they tagged something as documented in the wiki, even if the documentation is to be found in Proposed Features? I'm not a big fan of chaotic mapping, where people apply tags randomly without understanding how they're documented in the wiki, or apply tags without documenting their meaning in the wiki. IMHO, everything underneath Proposed_features should be moved into the real wiki (e.g. http://wiki.openstreetmap.org/wiki/Proposed_features/Key:stop should be moved to http://wiki.openstreetmap.org/wiki/Key:stop) and the feature should be labelled with 1) its current level of usage and 2) a measure of its controversiality (red / yellow / green). That would make it easier for OSM editors to point people to documentation. I do not fear anything. I have nothing against another system of approving. But at the moment approving by voting is described as the way to go. If there would be a consensus about another procedure I would be quite happy about that. But at the moment only some guys on talk said voting is silly, but that is not enough. If you think voting is silly, why do you not change the procedure of approving new features in the wiki? But it is not enough to say, that you want to abolish voting. Based on what facts a feature will be approved then. Or do you want to abolish proposed features completely? BTW the role of talk is too important. Why should new features be discussed on talk, IMO they should be discussed in the forum, a place which is much more accessible and modern and not so outdated like a mailing list. Some of the people here can not even handle it. Most discussion get completely off topic after 3 posts. A moderated forum with an integrated voting mechanism would be the best to introduce new features. lesi ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Potlatch, dual carriageways, and a broken changeset
Michal Migurski wrote: For live mode, clearly an undo feature would introduce more trouble than it's worth, for everyone involved in editing a particular area. Spot on. Potlatch's undo does function in live mode - it predates save mode, in fact - but it's not trivial and I wouldn't want to bet my life on it working in all circumstances. I try not to introduce differences between live and save mode (other than the obvious). Vector map editing is unfamiliar enough for most people; having an extra set of subtle differences in the UI depending on which mode you're in would, I think, be too confusing. Fortunately I figured a more obvious way to flag up that a way is locked (and how to unlock it) and coded it earlier; it'll be committed in the next couple of days when I've finished a few more changes. cheers Richard (Incidentally, Potlatch 2 doesn't have a live mode and I'm not anticipating that it will. Mind you, it doesn't have undo yet either. ;) ) -- View this message in context: http://old.nabble.com/Potlatch%2C-dual-carriageways%2C-and-a-broken-changeset-tp26239769p26249655.html Sent from the OpenStreetMap - General mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Why do you use Google Maps instead of OSM? Because of buildings...
On Saturday 07 Nov 2009 2:30:54 pm Ævar Arnfjörð Bjarmason wrote: Likewise setting up your own rendering takes half a day at best if you're not already familiar with the rendering tools involved. OSM reflects changes within minutes -- regards Kenneth Gonsalves Senior Project Officer NRC-FOSS http://nrcfosshelpline.in/web/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [talk-au] NearMap PhotoMap imagery for OSM
2009/11/6 Michael spam...@gmx-ist-cool.de: Attached is an updated patch that does not try to do the load balancing by itself and enables zoom levels up to 21. The corresponding download for -latest is @ http://rapidshare.com/files/303178932/slippymap.jar.html I'm not sure if it's because webkit-image is slow to download/merge images or what, but using the slippymap plugin loads the nearmap images a LOT faster, and you can turn off auto zoom also. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] NearMap PhotoMap imagery for OSM
2009/11/5 Peter Ross pe...@emailross.com: So for me source=nearmap is all that is needed. I've been thinking about this, if they're going to re-fly over cities, and judging by their existing WA imagery things on the images jump 1-2m in some cases, it might be useful to figure out the current imagery date and add that as well. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [Talk-de] Bald ist Weihnachten - Bäume und Mär kte
Am 7. November 2009 08:17 schrieb Jan Tappenbeck o...@tappenbeck.net: Moin ! auf dem letzten OSM-Stammtisch in Lübeck wurde die Idee geboren traditionelle Weihnachtsbäume und traditionelle Märkte zu mappen in der nächsten Zeit (also nichte jeden Vorgartenbaum und nicht jede Punschbude - schon mit Sinn und Verstand) und dann würde ich daraus eine Karte entsprechend [1] machen. Vielleicht läßt sich soetwas dann nochmal kurzfristig pressewirksam platzieren und so manchen für OSM interessierten sich für das Projekt zu entscheiden - keine Angst habe kein Provisionabkommen mit Garmin Co wenn die Frauen dann loslaufen zum kaufen. Eine entsprechende Wikiseite würde ich anlegen. Hier schon einmal meine Tag-Vorschläge Weihnachtsbaum amenity = christmas christmas = tree location = (z.B. Lübeck, vor dem Holstentor) Weihnachtsmarkt amenity = christmas christmas = market name = * (z.B. Lübecker Weihnachtsmarkt) location = (Lübeck, Rathausmarkt) opening_dates = 31.11.2009 - 31.12.2009 (deutsche schreibweise ??) opening_hours = Moin! Ich könnte mir Dinge, die nur wenige Wochen im Jahr vorhanden sind (und auch immer wieder anders) besser in einer Datenbank für temporäre Geschichten, wie z.B. auch Baustellen und deren Behelfsfahrbahnen, vorstellen. Weiter gehts dann nämlich mit dem Dorffest, der Kirmes, dem Schützenfest am gleichen Platz, diversen Musikfestivals mit wechselnden Orten etc. Wir mappen ja, was vor Ort ist und daher finde ich, daß dieses auch vor Ort überprüfbar sein sollte und das nicht nur zu einem bestimmten Termin. Das wäre doch eine gute Gelegenheit, eine solche zusätzliche Datenbank einfach mal aufzumachen und zu sehen, wie's läuft... Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bald ist Weihnachten - Bäume und Mär kte
Martin Simon schrieb: auf dem letzten OSM-Stammtisch in Lübeck wurde die Idee geboren traditionelle Weihnachtsbäume und traditionelle Märkte zu mappen in der nächsten Zeit (also nichte jeden Vorgartenbaum und nicht jede Punschbude - schon mit Sinn und Verstand) und dann würde ich daraus eine Karte entsprechend [1] machen. Ich könnte mir Dinge, die nur wenige Wochen im Jahr vorhanden sind (und auch immer wieder anders) besser in einer Datenbank für temporäre Geschichten, wie z.B. auch Baustellen und deren Behelfsfahrbahnen, vorstellen. +1 und wenn er es unbedingt in die OSM-DB eintragen will dann bitte als separater Name-Space, zB: xmas:feature=tree/market/glühweinstand xmas:name=name des features xmas:open_days=mo-fr xmas:open_time=17:00-23:00 Grüße Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bald ist Weihnachten - Bäume und Mär kte
Wir mappen ja, was vor Ort ist und daher finde ich, daß dieses auch vor Ort überprüfbar sein sollte und das nicht nur zu einem bestimmten Termin. nach Weihnachten würde ich alle Daten einmal extrahieren und in einer Liste mit JOSM-Remotezugriff listen - dann könnten betreffende im nächsten Jahr die Daten nur prüfen und gezielt anpassen. Ich dachte vielmehr auch als Ergebnis einer PR-Aktion. Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bald ist Weihnachten - Bäume und Mär kte
Chris-Hein Lunkhusen schrieb: Martin Simon schrieb: auf dem letzten OSM-Stammtisch in Lübeck wurde die Idee geboren traditionelle Weihnachtsbäume und traditionelle Märkte zu mappen in der nächsten Zeit (also nichte jeden Vorgartenbaum und nicht jede Punschbude - schon mit Sinn und Verstand) und dann würde ich daraus eine Karte entsprechend [1] machen. Ich könnte mir Dinge, die nur wenige Wochen im Jahr vorhanden sind (und auch immer wieder anders) besser in einer Datenbank für temporäre Geschichten, wie z.B. auch Baustellen und deren Behelfsfahrbahnen, vorstellen. +1 und wenn er es unbedingt in die OSM-DB eintragen will dann bitte als separater Name-Space, zB: xmas:feature=tree/market/glühweinstand xmas:name=name des features xmas:open_days=mo-fr xmas:open_time=17:00-23:00 Grüße Chris Hi ! und dann davor amenity=xmas Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Icons für verschiedene Treibststoffe
Thomas Reincke schrieb: Jan Tappenbeck schrieb: Danke ! guter Hinweis - wird schon einmal übernommen und da lt. Urheberangabe kein Rechtsschutz stellt ich die kleine Version auch in das OSM-Wiki. Das selbe gibt es auch für Erdgas-Tankstellen. http://commons.wikimedia.org/wiki/File:Zeichen_365-54.svg Tankstellen an denen es sowohl Autogas (LPG) als auch Erdgas (CNG) gibt habe vermutlich zwei Schilder. kennt denn noch einer ein Symbol oder eine allgemeine Farbe für BIODIESEL ??? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Hausnummernimport, wie würdet ihrs mac hen?
Hallo zusammen, ich habe einen Import von Hausnummern gemacht: http://osm.org/go/0JQWVejWS-- Nun sind die Hausnummern Nodes dort irgendwie immer so, dass sie quasi am Eingang des Hauses sind. Diese Information wollte ich nicht verlieren, deshalb habe ich Nodes importiert, statt dem zugehörigen Gebäude einfach die Nummern zu verpassen. Relationen zwischen Gebäude und Node sind im Hausnummernschema aber nicht vorgesehen. Was denkt ihr, sollte ich statt den Nodes doch besser einfach die Gebäude nummerieren? Gruss Sven -- Every time you use Google, you're using a Linux machine (Chris DiBona, a programs manager for Google) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Icons für verschiedene Treibststoffe
Jan Tappenbeck schrieb: Thomas Reincke schrieb: Jan Tappenbeck schrieb: Danke ! guter Hinweis - wird schon einmal übernommen und da lt. Urheberangabe kein Rechtsschutz stellt ich die kleine Version auch in das OSM-Wiki. Das selbe gibt es auch für Erdgas-Tankstellen. http://commons.wikimedia.org/wiki/File:Zeichen_365-54.svg Tankstellen an denen es sowohl Autogas (LPG) als auch Erdgas (CNG) gibt habe vermutlich zwei Schilder. kennt denn noch einer ein Symbol oder eine allgemeine Farbe für BIODIESEL ??? Leider nicht. Gegenfrage: Wie willst du das darstellen? Ich mein, wenn man sich [1] so anschaut gibt es ~20 verschiedene Arten von Kraftstoffen. Wenn man die Icons jetzt alle knapp nebeneinanderlegt, kann man wohl nix mehr erkennen. Oder willst du das andersherum machen: Ich brauche CNG, wo sind die Tankstellen? ... und dann werden nur die passenden angezeigt. Das wären dann ~20 Layer. Gruß, ULFL [1] http://wiki.openstreetmap.org/wiki/Approved_features/fuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummernimport, wie würdet ihrs mac hen?
Hallo, Sven Geggus wrote: Nun sind die Hausnummern Nodes dort irgendwie immer so, dass sie quasi am Eingang des Hauses sind. Diese Information wollte ich nicht verlieren, deshalb habe ich Nodes importiert, statt dem zugehörigen Gebäude einfach die Nummern zu verpassen. Relationen zwischen Gebäude und Node sind im Hausnummernschema aber nicht vorgesehen. Ich wuerde dem Gebaeude die Nummer geben - schliesslich werden nicht Eingaenge numeriert, sondern Gebaeude (oder?). Ich wuerde den Eingangsnode jedoch als Teil des Gebaeude-Umrisses beibehalten (mit geeignetem Tagging... keine Ahnung, was man nehmen koennte). Das sieht man dann auf der Karte nicht, aber ein Router koennte Dich zur richtigen Seite des Gebaeudes fuehren. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Icons für verschiedene Treibststoffe
Ulf Lamping schrieb: Gegenfrage: Wie willst du das darstellen? Ich mein, wenn man sich [1] so anschaut gibt es ~20 verschiedene Arten von Kraftstoffen. LPG, CNG, Wasserstoff und E85 braucht man -weil man ansonsten gar nicht, nur sehr eingeschränkt weiterfahren kann. Die anderen gibt es entweder überall, man braucht sie nicht oder man kann normalerweise auch etwas anderes tanken (z. B. 95 statt 91 Oktan oder normaler Diesel statt Biodiesel). Taggen kann man das freilich und ggf. an der Tanke mal als Mouseover/Popup anzeigen. Später mal am besten mit tagesaktuellen Preisen oder mindestems einem Link auf eine solche Seite. Oder willst du das andersherum machen: Ich brauche CNG, wo sind die Tankstellen? ... und dann werden nur die passenden angezeigt. Das wären dann ~20 Layer. Wenn Du mit einem monovalenten Erdgasauto unterwegs bist das alle 300 bis 400 km betankt werden musst und darüber hinaus nur einen 14 Liter Nottank für Luxusbrühe (Super Plus) hat wirst Du erwarten das Dich Dein Navi zur nächsten geeigneten Tanke führt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Icons für verschiedene Treibststoffe
Thomas Reincke schrieb: Ulf Lamping schrieb: Gegenfrage: Wie willst du das darstellen? Ich mein, wenn man sich [1] so anschaut gibt es ~20 verschiedene Arten von Kraftstoffen. LPG, CNG, Wasserstoff und E85 braucht man -weil man ansonsten gar nicht, nur sehr eingeschränkt weiterfahren kann. Die anderen gibt es entweder überall, man braucht sie nicht oder man kann normalerweise auch etwas anderes tanken (z. B. 95 statt 91 Oktan oder normaler Diesel statt Biodiesel). Taggen kann man das freilich und ggf. an der Tanke mal als Mouseover/Popup anzeigen. Später mal am besten mit tagesaktuellen Preisen oder mindestems einem Link auf eine solche Seite. Oder willst du das andersherum machen: Ich brauche CNG, wo sind die Tankstellen? ... und dann werden nur die passenden angezeigt. Das wären dann ~20 Layer. Wenn Du mit einem monovalenten Erdgasauto unterwegs bist das alle 300 bis 400 km betankt werden musst und darüber hinaus nur einen 14 Liter Nottank für Luxusbrühe (Super Plus) hat wirst Du erwarten das Dich Dein Navi zur nächsten geeigneten Tanke führt. Habe ich *irgendwo* die Sinnhaftigkeit der Aktion in Frage gestellt? Wenn du Strom brauchst, brauchst du Strom. Wenn du Oldtimer fährst reicht 95 Oktan u.U. auch nicht aus. In Italien siehst du dann gerne mal alt aus :-) ... Soviel zum die anderen haben keine Probleme mit dem normalen Angebot. Mir ging es darum, wie man sowas technisch hinbekommt damit es sinnvoll dargestellt wird. Das ist nämlich ein Problem, was wir nicht nur bei Tankstellen haben. Du hast meine Frage nicht ansatzweise beantwortet. Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummernimport, wie würdet ihrs mac hen?
Frederik Ramm schrieb: Hallo, Sven Geggus wrote: Nun sind die Hausnummern Nodes dort irgendwie immer so, dass sie quasi am Eingang des Hauses sind. Diese Information wollte ich nicht verlieren, deshalb habe ich Nodes importiert, statt dem zugehörigen Gebäude einfach die Nummern zu verpassen. Relationen zwischen Gebäude und Node sind im Hausnummernschema aber nicht vorgesehen. Ich wuerde dem Gebaeude die Nummer geben - schliesslich werden nicht Eingaenge numeriert, sondern Gebaeude (oder?). Ich wuerde den Eingangsnode jedoch als Teil des Gebaeude-Umrisses beibehalten (mit geeignetem Tagging... keine Ahnung, was man nehmen koennte). Das sieht man dann auf der Karte nicht, aber ein Router koennte Dich zur richtigen Seite des Gebaeudes fuehren. barrier=entrance Eine Hauswand ist ja auch eine barrier :-) Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummernimport, wie würdet ihrs m achen?
2009/11/7 Sven Geggus li...@fuchsschwanzdomain.de Hallo zusammen, ich habe einen Import von Hausnummern gemacht: http://osm.org/go/0JQWVejWS-- Nun sind die Hausnummern Nodes dort irgendwie immer so, dass sie quasi am Eingang des Hauses sind. Diese Information wollte ich nicht verlieren, deshalb habe ich Nodes importiert, statt dem zugehörigen Gebäude einfach die Nummern zu verpassen. Relationen zwischen Gebäude und Node sind im Hausnummernschema aber nicht vorgesehen. Einfach den Node in den Way des Gebäudes einfügen. Wenn du willst, kannst du dann eine building-Relation [1] erstellen. Dort den Hausumriss-way mit der Rolle outline und alle Eingansnodes (die mit der Adresse) mit der Rolle entrance einfügen. [1] http://wiki.openstreetmap.org/wiki/Relations/Proposed/Buildings ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Icons für verschiedene Treibststoffe
Ulf Lamping schrieb: Mir ging es darum, wie man sowas technisch hinbekommt damit es sinnvoll dargestellt wird. Das ist nämlich ein Problem, was wir nicht nur bei Tankstellen haben. Du hast meine Frage nicht ansatzweise beantwortet. Klick mal auf einer der Haltestellen http://öpnvkarte.de/?zoom=16lat=50.77671lon=6.08002layers=BT So könnte man die verfürbarkeit der 20 möglichen Sorten sinnvoll darstellen. Solch ein Fenster fände ich auch in der Standardkarte für POI sehr hilfreich. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wer zerteilt planet.osm? - war: Frage zu asia.osm von der Geofabrik
Moin, Stefan Dettenhofer (StefanDausR) schrieb: etwas anders organisiert und vor allem mit hoher Bandbreite am Netz. Morgen sollten die Daten dann dort zu finden sein. alles klar! Jetzt kannst Du loslegen: ftp://ftp5.gwdg.de/pub/misc/openstreetmap/teddynetz.de/latest/osm/ -- Viele Grüße Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Icons für verschiedene Treibststoffe
Thomas Reincke schrieb: Ulf Lamping schrieb: Mir ging es darum, wie man sowas technisch hinbekommt damit es sinnvoll dargestellt wird. Das ist nämlich ein Problem, was wir nicht nur bei Tankstellen haben. Du hast meine Frage nicht ansatzweise beantwortet. Klick mal auf einer der Haltestellen http://öpnvkarte.de/?zoom=16lat=50.77671lon=6.08002layers=BT So könnte man die verfürbarkeit der 20 möglichen Sorten sinnvoll darstellen. Solch ein Fenster fände ich auch in der Standardkarte für POI sehr hilfreich. Ja klar, so kann man das machen, mache ich bei mir [1] ja ähnlich. Dafür braucht man aber eigentlich auch keine unterschiedlichen Icons, was ja der Ursprung des Threads war :-) Gruß, ULFL P.S.: Das ist die erste osm Karte, die im MSIE ging und im Firefox nicht. Sonderzeichen in Servernamen scheinen doch keine s gute Idee zu sein ;-) [1] http://home.arcor.de/ulf.lamping/motorrad/karte/OpenLayers/map-full.html?zoom=13lat=46.82036lon=11.44271 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ?Hausnummernimport, wie würdet ihrs machen?
Robert S. osm-m...@autobahnen-europa.eu wrote: Einfach den Node in den Way des Gebäudes einfügen. Das geht nicht, weil der Hausnummernnode innerhalb der Gebäudeumrisse liegt. ich denke ich baue das doch so um, dass die Gebäude die Nummern bekommen. Sven -- Das Internet wird vor allem von Leuten genutzt, die sich Pornografie ansehen, während sie Bier trinken, es ist daher für Wahlen nicht geeignet (Jaroslaw Kaczynski) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OpenStreetView ?
Hallo Liste, weis von euch jemand wie es mit http://openstreetview.org/ weitergeht? Ich wollte gern ein paar Mappintouren dokumentieren und würde gern dazu dies Seite nutzen. Ciao Holger ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OZI Kalibrationsfile
Hallo, Mein Taho-Programm hatte 2 Probleme mit OZI: 1.: OZI konnte mit den 24Bit/Pixel PNGs nichts anfangen. Das ist inzwischen behoben, ich wandel sie nach 8 Bit 2.: Irgendetwas scheint mit den Kalibrationsfiles nicht zu stimmen, der Maßstab wird falsch angezeigt. Die Position der Karten ist aber richtig. Kennt sich hier jemand gut genug mit Ozi aus um mir da zu helfen. Ich selber benutze das Programm nicht. Zum Testen habe ich eine Karte + map-File gezipt und hier abgelegt: http://www.oche.de/~junker/tmp/OSM_z12_y343_x529_p1024.zip Gruß Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Relationen besser als Tags?
Dieses Posting befasst sich mit der Frage, ob die Eigenschaften von Straßen besser durch Relationen als durch Tags erfasst werden könnten. Bestandsaufnahme: Die Darstellung von Straßen in OSM geschieht momentan derart, dass ein Straßenabschnitt als Way erfasst wird. Manche Eigenschaften werden dabei durch Tags, andere durch Relationen beschrieben. Dabei sind die durch Tags beschriebenen Eigenschaften im Editor schon dann sichtbar, wenn man eine Straße anklickt. Bei den durch Relationen beschriebenen Eigenschaften ist dies erst über Umwege möglich. Daher werden die Relationseigenschaften von vielen Usern nicht wahrgenommen. Um die Eigenschaften Teilwegen zuzuordnen, ist derzeit eine Teilung der Wege erforderlich. Diese Notwendigkeit ist unabhängig davon, ob eine Eigenschaft durch Tag oder Relation dargestellt wird. Dies kann beispielsweise durch Maxspeed-Abschnitte, eine Brücke oder die Endhaltestelle einer Buslinie begründet sein. Insbesondere die Teilung wegen nicht offensichtlichen Relationen führt dazu, dass solche Teilungen von anderen Usern wieder gelöscht werden und die Relationen somit immer wieder zerstören. Unterbrochene oder plötzlich endende Radrouten - insbesondere deren Teile in weniger beobachteten ländlichen Gebieten - sprechen da Bände. Selbst für den Vor-Ort Wohnenden ist das Reparieren schlecht möglich, da er die Quelle der Radroute der original-editierenden Person nicht kennt. Ein anderes Beispiel: ÖPNV-Relationen werden durch die Umkehr einer Straßenrichtung zerstört. Weitere Begehrlichkeiten, wie das Darstellen der für die Routenplanung unumgänglichen durchgezogenen Mittellinie, welche gleichzeitig eine Wende- und Linksabbiegeverbot implizieren würde, ist derzeit nur aufwendig und realitätsfern möglich. Derzeit versucht man, die Funktionalität der durchgezogenen Mittellinie durch autobahnähnliche Trennung der Richtungsfahrbahnen oder durch Wendeverbot + Abbiegebeschränkung darzustellen, was beides eine sehr unbefriedigende und realitätsferne Lösung darstellt. Das Problem der Relationen ist es aber, dass sie beim derzeitigen Zustand von OSM nur schlecht sichtbar sind und vor allem Anfängern Probleme bereiten. Im Bereich des ÖPNV-Erfassung gibt es massive Probleme, die nur durch aufwendige Relationskonstruktionen, wie das Oxomoa-Konzept realisiert werden können, das aber wegen seiner Komplexität auf Ablehnung bei vielen User stößt, sofern man es überhaupt versteht. Entsprechend durchwachsen ist derzeit die Erfassung des ÖPNV, welche derzeit vollkommen uneinheitlich geschieht. Die Verwirrung neuer User ist groß. Nirgendwo können sie sich wirklich orientieren, da die Aussagen gegensätzlich sind. Zusammenfassung der Probleme: 1) Wie kann die versehentliche Zerstörung von Relationen verhindert werden? 2) Wie kann die Zerstückelung der Wege verhindert werden, die aufgrund der Beschreibung durch Tags bzw. Relationen notwendig ist? 3) Wie lässt sich die Erfassung der Eigenschaften teilweise durch Tags, teilweise durch Relationen vereinheitlichen? 4) Wie können dringend benötigte Eigenschaften für die korrekte Routenplanung in OSM gemappt und dargestellt werden? 5) Wie kann realitätsnäher gemappt werden und Ersatzmapping verhindert werden? 6) Wie wird Mapping und Darstellung auch schwieriger Zusammenhänge übersichtlicher, so dass sich hier zukünftig einheitliche Mappingkonzepte implizieren? 7) Lassen sich alle vorbeschriebenen Anforderungen mit einer einzigen Maßnahme erschlagen? Lösungsversuch: Ich nenne diesen Lösungsversuch Eigenschaftskonzept. Er soll versuchen, möglichst alle oben aufgeführten Fragen mit einem Schlag und dabei mit einem möglichst einfachen Konzept zu bewältigen: Man mappt die Straßen zunächst einmal als Grundgerüst. Jede Straße verläuft grundsätzlich ungeteilt zwischen den zwei nächsten Abzweigungen (bzw Kreuzungen). Eine Teilung der Straße ist also nur noch möglich, wenn eine neue Abzweigung eingefügt wird. Ansonsten ist eine Straße unteilbar. Die Straßen erhalten grundsätzlich keine Tags. Statt mit Tags werden die Eigenschaften grundsätzlich nur noch per Relation entlang eines Weges von hier bis dort zugeordnet: Von hier bis dort heißt die Straße XY-Straße. Von hier bis dort ist die Straße primary. Von hier bis dort befindet sich eine Brücke. Von hier bis dort ist die Straße Einbahnstraße. Von hier bis dort befindet sich eine durchgezogene Mittellinie. Von hier bis dort fährt die Buslinie XY. Von hier bis dort (und dort) befindet sich eine Abbiegebeschränkung. Jede Eigenschaftsrelation hat eine Richtung. All dies setzt allerdings voraus, dass die Editoren die Eigenschaftsrelationen genau so einfach sichtbar machen, wie bisher die Tags. Statt der Tags werden also bei Klick auf eine Straße alle Eigenschaftsrelationen angezeigt. Der Editor stellt das von hier bis dort in der Karte grafisch dar, wenn eine Eigenschaft angeklickt wird. Noch besser: Alle den geklickten Straßenabschnitt betreffenden Relationen werden farblich unterschiedlich angezeigt.
Re: [Talk-de] ?Hausnummernimport, wie würdet ihrs machen?
Sven Geggus schrieb: Robert S. osm-m...@autobahnen-europa.eu wrote: Einfach den Node in den Way des Gebäudes einfügen. Das geht nicht, weil der Hausnummernnode innerhalb der Gebäudeumrisse liegt. Dann könnte man ja prinzipiell den am nächsten liegenden Punkt auf dem Gebäudeumriss ermitteln, dort einen Eingangs-Node setzen und dem Gebäude die Hausnummern verpassen. Natürlich etwas mehr Aufwand. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Icons für verschiedene Treibststoffe
Am Sa November 7 2009 glaubte Ulf Lamping zu wissen: Gegenfrage: Wie willst du das darstellen? Ich mein, wenn man sich [1] so anschaut gibt es ~20 verschiedene Arten von Kraftstoffen. Wenn man die Icons jetzt alle knapp nebeneinanderlegt, kann man wohl nix mehr erkennen. Ich stelle mir gerade 4 Tankstellen mit großer Auswahl nebeneinander vor... da ist dann das halbe Viertel überdeckt. ;-) flo -- Now, you sons of 2-lost-world-war-bitches, even if, wich is most doubtful, you assholes managed to kill me, I would came back from the grave and haunt you. HA HA HA HA HA HA HA HA HA [Usenet Rulez in dag°] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen besser als Tags?
Hallo, Tirkon wrote: Ich nenne diesen Lösungsversuch Eigenschaftskonzept. Er soll versuchen, möglichst alle oben aufgeführten Fragen mit einem Schlag und dabei mit einem möglichst einfachen Konzept zu bewältigen: In die Richtung wurde schon oefters gedacht, eine rudimentaere Dokumentation ist hier: http://wiki.openstreetmap.org/wiki/Relations/Proposed/Segmented_Tag Einige Dinge kann man damit besser darstellen als jetzt, aber einige auch komplizierter. Einige Fehlerquellen werden ausgeschlossen, andere Fehlerquellen kommen neu hinzu (z.B. wer stellt sicher, dass die Punkte hier und dort tatsaechlich zur Strasse gehoeren; was ist, wenn jemand an die Strasse A-B-C-D die Eigenschaften von A-C ist die Strasse geteert und von B-D ist die Strasse ein Kiesweg anhaengt?) Dein Konzept von hier bis dort muesste noch verfeinert werden, es muss vemrmutlich ein von (aus/ein)schliesslich hier bis (aus/ein)schliesslich dort geben. Sonst ist bei einer Strasse A-B-C-D, die von A-B Altstrasse und von C-D Neustrasse heisst, unklar, wie sie zwischen B und C heisst ;-) All dies setzt allerdings voraus, dass die Editoren die Eigenschaftsrelationen genau so einfach sichtbar machen, wie bisher die Tags. Ja, das ist der Schwachpunkt, entweder muessen alle umdenken oder alle Software muss umgestrickt werden. Ein sanfter Wechsel ist die einzige Moeglichkeit, und dies wuerde zu einer langen Uebergangszeit fuehren, in der die gleiche Sache mal so, mal so ausgedrueckt wird. Die ueblichen Verdaechtigen wuerden sich auf talk-de ueber die Nutzlosigkeit von OSM echauffieren. Ausserdem muss entweder das Relationskonzept so angepasst werden, dass die abschnittsweise Mitgliedschaft eines Ways in einer Relation moeglich ist, oder Du musst eine zusaetzliche Ebene von Relationen einfuehren. Beispiel: Strasse A geht von Punkt X bis Punkt Y. An einem Punkt dazwischen, Punkt Z, der aber kein Kreuzungspunkt ist, verlaesst die Strasse das Ortsgebiet. Der Teil, der im Ortsgebiet ist, soll nun Mitglied der Ortsrelation werden. Ohne eine Aenderung des Datenmodells muesste man jetzt eine von dir so genannte Eigenschaftsrelation anlegen, die selbst keine Tags enthaelt, sondern die lediglich das Teilstueck der Strasse A von X bis Z beschreibt, und diese Eigenschaftsrelation muesste nun Mitglied der Ortsrelation werden. Wenn man in OpenStreetMap ein neues Konzept etablieren will, entfallen 20% der Arbeit auf die Ausarbeitung des neuen Konzepts und 80% darauf, sich zu ueberlegen, wie das Konzept in die Praxis umgesetzt werden kann, ohne dass dabei das Projekt monatelang angehalten werden muss, ohne dass hunderttausende Mapper umdenken muessen, ohne dass mit einem Bot die gesamte Datenbasis umgestrickt werden muss und ohne dass irgendein Diktator ein Machtwort sprechen muss. Wenn einem das gelingt, dann ist man gut ;-) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen besser als Tags?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tirkon schrieb: Relationseigenschaften von vielen Usern nicht wahrgenommen. Mir ist das auch schon des öfteren passiert. Lösungsversuch: Ich nenne diesen Lösungsversuch Eigenschaftskonzept. Er soll versuchen, möglichst alle oben aufgeführten Fragen mit einem Schlag und dabei mit einem möglichst einfachen Konzept zu bewältigen: Obwohl dies sicher schon oft diskutiert worden ist hat es doch einen soliden Kern, den es sich lohn weter zu verfolgen. Von mir ein dickes PRO! MfG Angie -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFK9YTbbWutCqbzQO0RAnlAAJ9EbrWjKu20fw9607Buv8X06UZHjwCfZBaW Kxd73wcp9gEj73oJUKBk3xs= =OOaS -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ?Hausnummernimport, wie würdet ihrs machen?
Tobias Knerr o...@tobias-knerr.de wrote: Dann könnte man ja prinzipiell den am nächsten liegenden Punkt auf dem Gebäudeumriss ermitteln, dort einen Eingangs-Node setzen und dem Gebäude die Hausnummern verpassen. Natürlich etwas mehr Aufwand. Ich fand das jetzt schon aufwendig genug die Nodes zu entfernen wenn sie innerhalb eines Gebäudes liegen und dann stattdessen einen Tag am Gebäude selbst anzubringen. So hab ich das jetzt gemacht und zwar mit Hilfe von Postgis (intersects) und einem kleinen Python-script, das mir eine neue OSM-Datei mit den geänderten Daten erzeugt hat. Gruss Sven -- Das Internet wird vor allem von Leuten genutzt, die sich Pornografie ansehen, während sie Bier trinken, es ist daher für Wahlen nicht geeignet (Jaroslaw Kaczynski) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Löschoperationen nicht in Historie Sei te?!?
Am Donnerstag, den 05.11.2009, 16:00 +0100 schrieb Candid Dauth: Mit meinem History Viewer (http://osm.cdauth.de/history-viewer/) versuche ich, auf diese Weise die Änderungen eines Changesets zu visualisieren. Die Analyse dauert entsprechend lange. Sehr cool. Das ist genau das was ich mir schon länger wünsche. Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hallo ich bin der Neue
Johannes Eiseler schrieb: Hallo zusammen, ich wollte mich kurz vorstellen. Johannes aus München. Hallo Johannes, viel Spaß beim mappen, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen besser als Tags?
Sehr gründliche Darstellung dieses alternativen Ansatzes! Vorweg einmal speziell hierzu: Tirkon schrieb: Relationen lassen wegen der längeren Basiswege schneller, einfacher und übersichtlicher zusammenklicken. Gerade kurze Abschnitte, wie beispielsweise Brücken, werden dort leicht vergessen. Dieser Nachteil des Zerstückelns von Ways lässt sich kurzfristig wesentlich leichter als mit einer kompletten Umkrempelung des Taggings lösen: Hierzu wäre es lediglich erforderlich. eine Wähle von hier [Klick] bis dort [Shift(?)+Klick] aus-Funktion in gängige Editoren einzubauen. Aus Benutzersicht vergleichbar wäre das mit dem Verhalten vieler Dateibrowser. Intern müsste eine Berechnung des kürzesten Weges zwischen den gewählten Nodes oder Ways erfolgen. Ein solches Feature würde das Mappen sowohl beim Setzen von Tags als auch beim Anlegen von Relationen deutlich beschleunigen, so dass ich es unabhängig von der Einführung relationsbasierter Eigenschaften begrüßen würde. Nun aber zum eigentlichen Thema: Die Eigenschaftsrelation nimmt normalerweise alle Linien als auch Punkte entlang eines Weges auf, um explizit punktförmige Ausschlüsse z.B. an Abzweigungen (oder Kreuzungen) deutlich zu machen. Wenn ich dich richtig verstehe, soll deine Lösung sich also deutlich von der von Frederik zitierten Segmented Tag-Idee unterscheiden? Begrüßen würde ich das - gerade wegen der Möglichkeit, Punkte nach ein- oder auszuschließen. In diesem Fall träfen natürlich auch verschiedene Kritikpunkte, etwa die Unterscheidung zwischen Ein- oder Ausschluss der Start- und Endpunkte, auf dein Modell nicht zu. 1) Funktioniert das Eigenschaftskonzept grundsätzlich? Das ist ziemlich eindeutig: Ja. Eine Erfassung über Relationen ist mächtiger als eine über Tags. Sie kann trivialerweise alles darstellen, was Tags darstellen können. Darüber hinaus kann sie einige Dinge repräsentieren, die - wie die von dir genannten ein- oder ausgeschlossenen Nodes bei einer Mittellinie - von Tags nicht darzustellen sind. Auch einige einige exotischere Fälle (etwa bedingte Eigenschaften) lassen sich wesentlich natürlicher abbilden. Die Ausdruckskraft spricht eindeutig für Relationen. Entscheidend für eine Umsetzung sind demnach eher diese Punkte hier: 2) Benutzerfreundlichkeit 5) Probleme bei der Umstellung auf das neue Modell Was hier vor allem von Interesse ist, ist die Handhabung in Editoren. Ein ausgearbeitetes Bedienkonzept für eine Editor-Integration von Eigenschaftsrelationen wäre meines Erachtens das entscheidende Argument für eine Machbarkeit der Idee. Den schrittweisen Übergang auf das neue Modell sehe ich in technischer Hinsicht dann gar nicht als so großes Problem an. Bei den meisten Eigenschaften lässt sich schließlich auf verhältnismäßig primitive Weise eine Konversion in Tag-basierte Ansätze durchführen, so dass bestehende Anwendungen mit geringen Modifikationen auf den entsprechend eingetragenen Daten arbeiten könnten. Die Überzeugungsarbeit ist natürlich wieder ein anderes Thema - und auch hier würde der Machbarkeitsbeleg durch ein Editor-Bedienkonzept deutlich weiterhelfen. Wenn der Ansatz Eigenschaftsrelation also weiterverfolgt werden soll - und ich befürworte das ganz klar -, dann würde ich ein solches Konzept als ersten großen Arbeitsschritt ansehen. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] JOSM: PicLayer !!
Hi ! ich möchte gerne georef. Bilder machen und dann etwas abzeichen - doch JOSM (2388) meldet immer das Piclayer abschaltet werden muss und nicht funktioniert. Weiß einer genaueres ? gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen besser als Tags?
Tobias Knerr o...@tobias-knerr.de wrote: Die Überzeugungsarbeit ist natürlich wieder ein anderes Thema - und auch hier würde der Machbarkeitsbeleg durch ein Editor-Bedienkonzept deutlich weiterhelfen. Wenn der Ansatz Eigenschaftsrelation also weiterverfolgt werden soll - und ich befürworte das ganz klar -, dann würde ich ein solches Konzept als ersten großen Arbeitsschritt ansehen. Unabhängig von der Art eines neuen Konzeptes, das einen Umbau der Datenbank erfordert, könnte ein möglicher Übergang durch ein zweites, paralleles OSM erfolgen. Dann kann man der Community freien Lauf lassen, wie sie OSM 1.0 in OSM 2.0 überführen möchte. Teile könnten durch Bots erfolgen, andere Teile Handarbeit notwendig machen. Voraussetzung dafür ist natürlich eine sehr breite Zustimmung für ein neues Konzept innerhalb der Community. So könnte das Umdenken der User so langsam wie erforderlich stattfinden und mögliche Konzeptkorrekturen am lebenden Modell erprobt werden. Ich denke aber mal, dass ein gutes Konzept, das dem User als auch dem Programmierer der Anwendungen von vielen Beschwerlichkeiten und Begrenzungen eines alten Konzeptes befreit und zudem durchsichtiger ist, dem neuen OSM die User in Scharen zutreiben würde. Wenn dann OSM 1.0 verwaist, dann wird die Umschaltung auf OSM 2.0 schneller erfolgen, als mancher zu träumen gewagt hätte. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Straßenliste München
Pflege der Straßenliste für München. Ich habe schon mehrfach eine Mail an Florian Lohoff gesandt, leider scheinen die Mais nich mehr unter f...@rfc822.org zu landen? Hier nochmals die Bitte die Messnergasse aus der Straßenliste zu streichen, diese Straße gibt es in München nicht! Wenn diese Straße gestrichen wurde, können wir für München eine 100% Straßenerfassung melden. HIP HIP HURRA :-) Schöne Grüße aus München Ludwich ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Was macht OSM in Deutschland so erfolgreich?
In einem Posting in dieser Mailingliste bittet Henk Hoff als Vorsitzender des Organisationkomitees der SOTM 2010 (international) in seinem Posting SotM10 in Deutschland (oder Oestenreich / Schweiz): um Meldungen aus Berlin, Karlsruhe oder München. Als Grund für eine Ausrichtung in Deutschland schreibt er: Viele Leute im Ausland sind sehr interessiert in den riesen Erfolg der deutschen OpenStreetMap Community. Ich denke einmal, dass eine SOTM (international) in Deutschland (statt anderswo) kaum jemand vor Augen führen könnte, warum dies so ist. Henk Hoffs Posting blieb bisher gänzlich unbeantwortet. Scheinbar ist es so, dass der Riesenerfolg der deutschen OSM-Community weder das Gesamtprojekt oder gar eine örtliche Abordnung in die Lage versetzt, eine solche Veranstaltung eben mal zu schultern. Bei der Suche nach einer möglichen Antwort auf Henk Hoffs Posting stellte sich mir selbst die Frage: Was macht OSM eigentlich in Deutschland eigentlich so erfolgreich? Die örtlichen Treffen sind eher beschaulich und überblickbar und wälzen auch keine weltbewegenden Themen. Eine deutsche SOTM gab es bisher nicht. Die Programmierer der einzelnen OSM-bezogenen Programme arbeiten so ziemlich für sich und stimmen sich wenig ab. Auch die Kommunikation der Mapper untereinander beschränkt sich eher auf Einzelgespräche über den OSM Account. Vergleichsweise wenige beteiligen sich an den Diskussionen in Mailingliste und Forum. Und das deutsche Wiki hat weniger Umfang, als das englische. Im Moment kommt es mir bei OSM Deutschland so vor, wie in diesem nicht ganz ernst gemeinten Erklärungsversuch: Frage: Was ist der Unterschied zwischen Wissenschaft und Technik? Die Wissenschaft weiß alles, aber nichts funktioniert. Technik ist, wenn alles funktioniert, aber keiner weiß warum. Bei OSM Deutschland scheint mir derzeit der zweite Fall vorzuliegen. Oder weiß tatsächlich jemand, warum es in Deutschland besser funktioniert, als anderswo? ... wegen der hohen Postingfrequenz in der Mailingliste? ... weil es viele Mapper gibt? ... weil der einzelne Mapper fleißig ist? ... weil der Mapper informiert ist ... wegen vieler Bots? ... wegen der vielen Hilfsprogramme und Fehlersuchaktionen? ... wegen solcher und ähnlicher Einzelaktionen?: http://wiki.openstreetmap.org/wiki/DE:Kommunikation ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Was macht OSM in Deutschland so erfolgreich?
Am 07.11.2009 um 21:08 schrieb Tirkon: In einem Posting in dieser Mailingliste bittet Henk Hoff als Vorsitzender des Organisationkomitees der SOTM 2010 (international) in seinem Posting SotM10 in Deutschland (oder Oestenreich / Schweiz): um Meldungen aus Berlin, Karlsruhe oder München. Als Grund für eine Ausrichtung in Deutschland schreibt er: Viele Leute im Ausland sind sehr interessiert in den riesen Erfolg der deutschen OpenStreetMap Community. Ich denke einmal, dass eine SOTM (international) in Deutschland (statt anderswo) kaum jemand vor Augen führen könnte, warum dies so ist. Henk Hoffs Posting blieb bisher gänzlich unbeantwortet. Scheinbar ist es so, dass der Riesenerfolg der deutschen OSM-Community weder das Gesamtprojekt oder gar eine örtliche Abordnung in die Lage versetzt, eine solche Veranstaltung eben mal zu schultern. Viele, vllt. auch nur einige, sind der Meinung, dass eine SOTM in Deutschland zu dem jetzigen Zeitpunkt nicht so sinnvoll wäre. Es ist besser eine SOTM in einem Land zu haben, dass eben noch nicht so weit in OSM entwickelt ist und dass sich durch die mit der SOTM einhergehende Aufmerksamkeit (in den Medien) weiterentwickeln kann. Außerdem gibt es nächstes Jahr noch die Fossgis als deutsche OSM- Konferenz, dann muss man nicht unbedingt auch noch die SOTM in Deutschland machen. Bei der Suche nach einer möglichen Antwort auf Henk Hoffs Posting stellte sich mir selbst die Frage: Was macht OSM eigentlich in Deutschland eigentlich so erfolgreich? Die örtlichen Treffen sind eher beschaulich und überblickbar und wälzen auch keine weltbewegenden Themen. Eine deutsche SOTM gab es bisher nicht. Die Programmierer der einzelnen OSM-bezogenen Programme arbeiten so ziemlich für sich und stimmen sich wenig ab. Auch die Kommunikation der Mapper untereinander beschränkt sich eher auf Einzelgespräche über den OSM Account. Vergleichsweise wenige beteiligen sich an den Diskussionen in Mailingliste und Forum. Und das deutsche Wiki hat weniger Umfang, als das englische. Im Moment kommt es mir bei OSM Deutschland so vor, wie in diesem nicht ganz ernst gemeinten Erklärungsversuch: Frage: Was ist der Unterschied zwischen Wissenschaft und Technik? Die Wissenschaft weiß alles, aber nichts funktioniert. Technik ist, wenn alles funktioniert, aber keiner weiß warum. Bei OSM Deutschland scheint mir derzeit der zweite Fall vorzuliegen. Oder weiß tatsächlich jemand, warum es in Deutschland besser funktioniert, als anderswo? Suche mal nach alten Threads von Talk-de, Hurricane McEwen hat damals mal gefragt. Außerdem hier: http://blog.geofabrik.de/?p=13 Ich denke damit sind dann auch alle Begründungen, die mir einfallen würden abgedeckt. Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenliste München
Ludwich schrieb: Messnergasse aus der Straßenliste zu streichen, diese Straße gibt es in München nicht! Sicher? Ich habe sie auch schon erfolglos gesucht, aber immerhin ist sie in der Straßenreinigungssatzung aufgeführt - und anscheinend auch im Bebauungsplan für das Gebiet Herrnstraße/Stollbergstraße. (Der ist leider noch nicht online verfügbar, müsste aber wohl im Vermessungsamt ausliegen.) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Was macht OSM in Deutschland so erfolgreich?
Hallo, Tirkon schrieb: ... wegen der hohen Postingfrequenz in der Mailingliste? ... weil es viele Mapper gibt? ... weil der einzelne Mapper fleißig ist? ... weil der Mapper informiert ist ... wegen vieler Bots? ... wegen der vielen Hilfsprogramme und Fehlersuchaktionen? ... wegen solcher und ähnlicher Einzelaktionen?: Ich glaube das liegt zu einem großen Teil an der Schrebergartenmentalität. Jeder möchte sein Gebiet so schön wie möglich machen, eben besser oder mindestens genausogut wie der Gartennachbar. -- Viele Gruesse Computerteddy ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenliste München
Ulf Möller schrieb: Ludwich schrieb: Messnergasse aus der Straßenliste zu streichen, diese Straße gibt es in München nicht! Sicher? Ich habe sie auch schon erfolglos gesucht, aber immerhin ist sie in der Straßenreinigungssatzung aufgeführt - und anscheinend auch im Bebauungsplan für das Gebiet Herrnstraße/Stollbergstraße. (Der ist leider noch nicht online verfügbar, müsste aber wohl im Vermessungsamt ausliegen.) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Die Straßenreinigungssatzung auf die du dich beziehst ist von 1979, da wurden noch Karteikarten geschubst und mit Bleistift und Radiegummi agiert ;-) Diese Straße ist nirgendwo anders zu finden, sollte sie dennoch auftauchen werden wir sie natürlich sofort integrieren. Der beschriebene Bebauungsplan sollte ja dann auch mal ans Licht der Öffentlichkeit kommen. Also jetzt am besten den Iststand abbilden sprich100% %-) Schönen Gruß Ludwich StraßenreinigungsS 240 Satzung über die Straßenreinigu München (Straßenreinigungssatzung vom 4. Dezember 1979 Stadtratsbeschluss: 28.11.1979 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen besser als Tags?
Frederik Ramm frede...@remote.org wrote: Einige Dinge kann man damit besser darstellen als jetzt, aber einige auch komplizierter. Einige Fehlerquellen werden ausgeschlossen, andere Fehlerquellen kommen neu hinzu (z.B. wer stellt sicher, dass die Punkte hier und dort tatsaechlich zur Strasse gehoeren; Dazu schrieb ich: Statt mit Tags werden die Eigenschaften grundsätzlich nur noch per Relation entlang eines Weges von hier bis dort zugeordnet: Man beachte entlang eines Weges Natürlich rastet der Editor nur dort ein. was ist, wenn jemand an die Strasse A-B-C-D die Eigenschaften von A-C ist die Strasse geteert und von B-D ist die Strasse ein Kiesweg anhaengt?) Doppeltes Eigenschafts-Taggen eines gleichen Abschnittes bleibt - wie bisher - ausgeschlossen und ist vom Editor zurückzuweisen. Dein Konzept von hier bis dort muesste noch verfeinert werden, es muss vemrmutlich ein von (aus/ein)schliesslich hier bis (aus/ein)schliesslich dort geben. (aus/ein)schliesslich ... ist durch den beschriebenen Aus- bzw Einschluss von Punkten in der Eigenschaftsrelation beschreibbar. Sonst ist bei einer Strasse A-B-C-D, die von A-B Altstrasse und von C-D Neustrasse heisst, unklar, wie sie zwischen B und C heisst ;-) Ich verstehe nicht ganz, was davon abhält, B-C mit Uraltstraße, Altstraße oder Neustraße zu benamen und wozu Du hier das (aus/ein)schliesslich brauchst? Bei Straßennamen die sich an Abzweigungen treffen, könnte man ein (aus/ein)schliesslich getrost ignorieren und so, wie bisher verfahren. All dies setzt allerdings voraus, dass die Editoren die Eigenschaftsrelationen genau so einfach sichtbar machen, wie bisher die Tags. Ja, das ist der Schwachpunkt, entweder muessen alle umdenken oder alle Software muss umgestrickt werden. Ein sanfter Wechsel ist die einzige Moeglichkeit, und dies wuerde zu einer langen Uebergangszeit fuehren, in der die gleiche Sache mal so, mal so ausgedrueckt wird. Die ueblichen Verdaechtigen wuerden sich auf talk-de ueber die Nutzlosigkeit von OSM echauffieren. Sei froh ;-) Ansonsten hättest Du einen Running Gag in Deinen Vorträgen weniger ;-) Ausserdem muss entweder das Relationskonzept so angepasst werden, dass die abschnittsweise Mitgliedschaft eines Ways in einer Relation moeglich ist, oder Du musst eine zusaetzliche Ebene von Relationen einfuehren. Beispiel: Strasse A geht von Punkt X bis Punkt Y. An einem Punkt dazwischen, Punkt Z, der aber kein Kreuzungspunkt ist, verlaesst die Strasse das Ortsgebiet. Der Teil, der im Ortsgebiet ist, soll nun Mitglied der Ortsrelation werden. Ohne eine Aenderung des Datenmodells muesste man jetzt eine von dir so genannte Eigenschaftsrelation anlegen, die selbst keine Tags enthaelt, sondern die lediglich das Teilstueck der Strasse A von X bis Z beschreibt, und diese Eigenschaftsrelation muesste nun Mitglied der Ortsrelation werden. Dazu schrieb ich: Lediglich an den Endpunkten der Relation oder beispielsweise bei Bushaltestellen ist wegen der genauen Lokalisierung ein Umschalten auf Micro-Erfassung notwendig. Ein neu eingefügter Micro-Punkt der Eigenschaftsrelation wird automatisch in den Way und alle anderen Relationen übernommen Mir ist klar, dass noch Einiges zu Ende gedacht werden muss und überlegt werden, wie man auch solche Probleme einfach und weinheitlich editierbar hält. Aber irgendwo muss man beginnen, Tachyles zu reden, die Probleme zusammenzufassen, und Lösungsansätze anzudenken. Ich vermute, dass Deine konkret an Einzelpunkten festgemachte Kritik als Anzeichen zu werten ist, dass Du das Eigenschaftskonzept nicht grundsätzlich ablehnst, sondern die Schwierigkeiten an anderer Stelle siehst. Wenn man in OpenStreetMap ein neues Konzept etablieren will, entfallen 20% der Arbeit auf die Ausarbeitung des neuen Konzepts und 80% darauf, sich zu ueberlegen, wie das Konzept in die Praxis umgesetzt werden kann, ohne dass dabei das Projekt monatelang angehalten werden muss, ohne dass hunderttausende Mapper umdenken muessen, ohne dass mit einem Bot die gesamte Datenbasis umgestrickt werden muss und ohne dass irgendein Diktator ein Machtwort sprechen muss. Wenn einem das gelingt, dann ist man gut ;-) In der Antwort auf das erste Posting von Tobias Knerr in diesem Thread findest Du meinen Vorschlag zum möglichen Übergang auf ein eventuelles OSM 2.0, den ich zur Vermeidung einer Diskussiondispersion hier nicht wiederholen möchte. Ich hoffe, der Vorschlag ist gut genug ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen besser als Tags?
Tirkon tirko...@yahoo.de wrote: Dieses Posting befasst sich mit der Frage, ob die Eigenschaften von Straßen besser durch Relationen als durch Tags erfasst werden könnten. Bestandsaufnahme: Die Darstellung von Straßen in OSM geschieht momentan derart, dass ein Straßenabschnitt als Way erfasst wird. Manche Eigenschaften werden dabei durch Tags, andere durch Relationen beschrieben. Dabei sind die durch Tags beschriebenen Eigenschaften im Editor schon dann sichtbar, wenn man eine Straße anklickt. Bei den durch Relationen beschriebenen Eigenschaften ist dies erst über Umwege möglich. Daher werden die Relationseigenschaften von vielen Usern nicht wahrgenommen. Um die Eigenschaften Teilwegen zuzuordnen, ist derzeit eine Teilung der Wege erforderlich. Diese Notwendigkeit ist unabhängig davon, ob eine Eigenschaft durch Tag oder Relation dargestellt wird. Dies kann beispielsweise durch Maxspeed-Abschnitte, eine Brücke oder die Endhaltestelle einer Buslinie begründet sein. Insbesondere die Teilung wegen nicht offensichtlichen Relationen führt dazu, dass solche Teilungen von anderen Usern wieder gelöscht werden und die Relationen somit immer wieder zerstören. Unterbrochene oder plötzlich endende Radrouten - insbesondere deren Teile in weniger beobachteten ländlichen Gebieten - sprechen da Bände. Selbst für den Vor-Ort Wohnenden ist das Reparieren schlecht möglich, da er die Quelle der Radroute der original-editierenden Person nicht kennt. Ein anderes Beispiel: ÖPNV-Relationen werden durch die Umkehr einer Straßenrichtung zerstört. Weitere Begehrlichkeiten, wie das Darstellen der für die Routenplanung unumgänglichen durchgezogenen Mittellinie, welche gleichzeitig eine Wende- und Linksabbiegeverbot implizieren würde, ist derzeit nur aufwendig und realitätsfern möglich. Derzeit versucht man, die Funktionalität der durchgezogenen Mittellinie durch autobahnähnliche Trennung der Richtungsfahrbahnen oder durch Wendeverbot + Abbiegebeschränkung darzustellen, was beides eine sehr unbefriedigende und realitätsferne Lösung darstellt. Das Problem der Relationen ist es aber, dass sie beim derzeitigen Zustand von OSM nur schlecht sichtbar sind und vor allem Anfängern Probleme bereiten. Im Bereich des ÖPNV-Erfassung gibt es massive Probleme, die nur durch aufwendige Relationskonstruktionen, wie das Oxomoa-Konzept realisiert werden können, das aber wegen seiner Komplexität auf Ablehnung bei vielen User stößt, sofern man es überhaupt versteht. Entsprechend durchwachsen ist derzeit die Erfassung des ÖPNV, welche derzeit vollkommen uneinheitlich geschieht. Die Verwirrung neuer User ist groß. Nirgendwo können sie sich wirklich orientieren, da die Aussagen gegensätzlich sind. Zusammenfassung der Probleme: 1) Wie kann die versehentliche Zerstörung von Relationen verhindert werden? 2) Wie kann die Zerstückelung der Wege verhindert werden, die aufgrund der Beschreibung durch Tags bzw. Relationen notwendig ist? 3) Wie lässt sich die Erfassung der Eigenschaften teilweise durch Tags, teilweise durch Relationen vereinheitlichen? 4) Wie können dringend benötigte Eigenschaften für die korrekte Routenplanung in OSM gemappt und dargestellt werden? 5) Wie kann realitätsnäher gemappt werden und Ersatzmapping verhindert werden? 6) Wie wird Mapping und Darstellung auch schwieriger Zusammenhänge übersichtlicher, so dass sich hier zukünftig einheitliche Mappingkonzepte implizieren? 7) Lassen sich alle vorbeschriebenen Anforderungen mit einer einzigen Maßnahme erschlagen? Lösungsversuch: Ich nenne diesen Lösungsversuch Eigenschaftskonzept. Er soll versuchen, möglichst alle oben aufgeführten Fragen mit einem Schlag und dabei mit einem möglichst einfachen Konzept zu bewältigen: Man mappt die Straßen zunächst einmal als Grundgerüst. Jede Straße verläuft grundsätzlich ungeteilt zwischen den zwei nächsten Abzweigungen (bzw Kreuzungen). Eine Teilung der Straße ist also nur noch möglich, wenn eine neue Abzweigung eingefügt wird. Ansonsten ist eine Straße unteilbar. Die Straßen erhalten grundsätzlich keine Tags. Statt mit Tags werden die Eigenschaften grundsätzlich nur noch per Relation entlang eines Weges von hier bis dort zugeordnet: Von hier bis dort heißt die Straße XY-Straße. Von hier bis dort ist die Straße primary. Von hier bis dort befindet sich eine Brücke. Von hier bis dort ist die Straße Einbahnstraße. Von hier bis dort befindet sich eine durchgezogene Mittellinie. Von hier bis dort fährt die Buslinie XY. Von hier bis dort (und dort) befindet sich eine Abbiegebeschränkung. Jede Eigenschaftsrelation hat eine Richtung. All dies setzt allerdings voraus, dass die Editoren die Eigenschaftsrelationen genau so einfach sichtbar machen, wie bisher die Tags. Statt der Tags werden also bei Klick auf eine Straße alle Eigenschaftsrelationen angezeigt. Der Editor stellt das von hier bis dort in der Karte grafisch dar, wenn eine Eigenschaft angeklickt wird. Noch besser: Alle den geklickten Straßenabschnitt betreffenden Relationen werden
Re: [Talk-de] Was macht OSM in Deutschland so erfolgreich?
Ich glaube das liegt zu einem großen Teil an der Schrebergartenmentalität. Jeder möchte sein Gebiet so schön wie möglich machen, eben besser oder mindestens genausogut wie der Gartennachbar. Wenn es wirklich daran liegt bin ich Falsch dabei. Mein Anfangsimpuls war Schlicht und Einfach: - die gekaufte NAVI Karte ist mir zu teuer - ich such nach einer Alternative - finde OSM - das was ich oft nutze kann ich selbst optimiern und kann von dem profitieren was andere optimiert haben. Ich bin begeistern von Karten sie so detailliert sind wie die um Stuttgart herum, und Freue mich wenn nicht nur ich, sondern andere um mich herum die Karte hier in der Gegend Stück für Stück so weit verbessern, dass ich bei meiner nächsten Tour Wege finde, die mit keinem anderen Navi in Deutschland oder sogar Weltweit zu finden wären. Dass ich sicher an Ziele in Ortschaften geführt werden, die ich mit keiner anderen Karte finden würde. Darum: Optimierte Wege in den Ortschaften, bis hin zu kleinen Feld- und Waldwegen. und eine Verbesserung der Eingabe von POI damit ich mit meinem GARMIN Insider-Tipps finde, die in keinem Stadtführer stehen. (Gerade in Leipzig so erlebt) Das hat aus meiner Sicht mit Schrebergarten-Gartenzwergmetalität nichts zu tun. Das ist für mich der pure Spaß an der OSM Karte. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Was macht OSM in Deutschland so erfolgreich?
Hi, Jonas Krückel wrote: Henk Hoffs Posting blieb bisher gänzlich unbeantwortet. Scheinbar ist es so, dass der Riesenerfolg der deutschen OSM-Community weder das Gesamtprojekt oder gar eine örtliche Abordnung in die Lage versetzt, eine solche Veranstaltung eben mal zu schultern. Viele, vllt. auch nur einige, sind der Meinung, dass eine SOTM in Deutschland zu dem jetzigen Zeitpunkt nicht so sinnvoll wäre. Es ist besser eine SOTM in einem Land zu haben, dass eben noch nicht so weit in OSM entwickelt ist und dass sich durch die mit der SOTM einhergehende Aufmerksamkeit (in den Medien) weiterentwickeln kann. Außerdem gibt es nächstes Jahr noch die Fossgis als deutsche OSM- Konferenz, dann muss man nicht unbedingt auch noch die SOTM in Deutschland machen. +1 Das sind auch fuer mich die Hauptgruende. Um eine Konferenz wie die SOTM zu stemmen, braucht es keine tausend Aktiven und keine grossflaechige OSM-Abdeckung. Dafuer reicht ein Kernteam von 4, 5 guten, aktiven Leuten, die ranklotzen koennen und wollen. Das geht in fast jedem Land. Die SOTM hat im Laufe ihrer drei Jahre immer staerker einen nach aussen gewendeten Charakter bekommen. Spaetestens seit Amsterdam empfinde ich die SOTM weniger ein Community-Treffen, sondern mehr ein Schaulaufen fuer Politik und Wirtschaft: Schaut her, was wir tolles koennen! Eine solche Konferenz kann, finde ich, in einem Land, in dem OSM noch nicht so fortgeschritten ist, mehr Nutzen stiften. Die deutschen OSMer wissen, dass sie gut sind - sie brauchen sich nicht zu treffen und uns alle gegenseitig auf die Schulter zu klopfen ;-) (Mal ganz ehrlich - ich bin ja gern dabei, die talk-de-Miesepetrigkeit a la OSM taugt nichts und wird untergehen anzuprangern, aber auf der SOTM in Amsterdam hatte ich gerade das gegensaetzliche Gefuehl; da war alles grossartig, alles toll, die Zukunft nur rosig, alle waren Freunde und ueber Probleme redet man nicht. Fast so, als ob man das tolle Image nach aussen nicht beschmutzen wollte. Das war mir dann auch ein bisschen zu viel des Guten.) Tirkon hat recht, wenn er schreibt, dass wir hier in Deutschland ziemlich viel nebeneinander her wurschteln anstatt zusammen. Vielleicht ist das das Geheimnis unseres Erfolgs - weniger Bier, mehr Arbeit! Aber ich hoffe, dass die FOSSGIS im Maerz genuegend Anlass fuer alle Aktiven in der Community gibt, sich kennenzulernen und eventuell auch mal zusammen was anzufangen. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Was macht OSM in Deutschland so erfolgreich?
Carsten Schwede computerte...@gmx.de wrote: Ich glaube das liegt zu einem großen Teil an der Schrebergartenmentalität. Jeder möchte sein Gebiet so schön wie möglich machen, eben besser oder mindestens genausogut wie der Gartennachbar. Das kann ich nur unterschreiben. Ich hatte mir für 2009 vorgenommen in meinem Heimatdorf jeden Feldweg zu erfassen. Ich bin fast fertig :) Sven -- If we want hardware to work to its full potential, we need to claim to be a recent version of Windows. (Matthew Garrett) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Was macht OSM in Deutschland so erfolgreich?
UMAX974 umax...@googlemail.com wrote: Ich glaube das liegt zu einem großen Teil an der Schrebergartenmentalität. Jeder möchte sein Gebiet so schön wie möglich machen, eben besser oder mindestens genausogut wie der Gartennachbar. Wenn es wirklich daran liegt bin ich Falsch dabei. Mein Anfangsimpuls war Schlicht und Einfach: - die gekaufte NAVI Karte ist mir zu teuer - ich such nach einer Alternative - finde OSM - das was ich oft nutze kann ich selbst optimiern und kann von dem profitieren was andere optimiert haben. Ich bin begeistern von Karten sie so detailliert sind wie die um Stuttgart herum, und Freue mich wenn nicht nur ich, sondern andere um mich herum die Karte hier in der Gegend Stück für Stück so weit verbessern, dass ich bei meiner nächsten Tour Wege finde, die mit keinem anderen Navi in Deutschland oder sogar Weltweit zu finden wären. Dass ich sicher an Ziele in Ortschaften geführt werden, die ich mit keiner anderen Karte finden würde. Du hast natürlich recht damit, dass dies ein Argument für die Mitarbeit bei OSM ist. Dieses Argument gilt aber für den Bewohner eines jeden Staates. Es muss also ein bißchen mehr hinter den hiesigen Zuständen stecken - wenn nicht bei Dir, dann zumindest bei Anderen. Also keine Sorge, dass Du hier fasch sein könntest - Jede Intention ist natürlich willkommen. Es zählt das Ergebnis ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bilder auf OSM-Karte einbinden
Habe ich übrigens hier her: http://www.openlayers.org/dev/examples/example-list.html Links dann auf Popup Matrix klicken. MfG ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Was macht OSM in Deutschland so erfolgreich?
Frederik Ramm frede...@remote.org wrote: (Mal ganz ehrlich - ich bin ja gern dabei, die talk-de-Miesepetrigkeit a la OSM taugt nichts und wird untergehen anzuprangern, aber auf der SOTM in Amsterdam hatte ich gerade das gegensaetzliche Gefuehl; da war alles grossartig, alles toll, die Zukunft nur rosig, alle waren Freunde und ueber Probleme redet man nicht. Fast so, als ob man das tolle Image nach aussen nicht beschmutzen wollte. Das war mir dann auch ein bisschen zu viel des Guten.) Danke für den Einblick in das, was außerhalb der Videos abging :-) Ich denke, OSM hat das nicht nötig. Es werden ohnehin die Zeiten kommen, wo sich die Presse auf die ersten unvermeidlichen Negativschlagzeilen bei OSM stürzt. Wir erleben es am Beispiel der deutschen Wikipedia, wo die derzeitig anstehende Entscheidung zur Inklusion/Exklusion fast zum Scheideweg zwischen Überleben und Sterben hochstilisiert wird. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Was macht OSM in Deutschland so erfolgreich?
Carsten Schwede computerte...@gmx.de wrote: Ich glaube das liegt zu einem großen Teil an der Schrebergartenmentalität. Jeder möchte sein Gebiet so schön wie möglich machen, eben besser oder mindestens genausogut wie der Gartennachbar. Ahja, gute Erklärung und geniale Analogie. Dann entsprechen die derzeit immer häufiger diskutierten Tags für teils hochspezifische Dinge den bei OSM noch aufzustellenden Gartenzwergen ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wie erfasst ihr Hausnummern?
Hallo, viel ist schon getan und es werden immer mehrAdressen getagt. Welche komfortablen Möglichkeiten mit erschwinglichen Geräten haben sich dafür bewährt. Ich benutze z. Zeit folgendes: 1. Laptop mit Bluetooth logger Holux M-241 und JOSM mit livegps. Nachteil: Geht nur mit PKW und Stop für jeden Eintrag einer Hausunummer 2. Walking Paper und Adressen grob auf dem Papierausdruck einzeichen und dann weiter verarbeiten. Wäre das eine optimale Lösung: 3. Günstiges Handy mit Bluetooth (oder Einbau GPS) mit synchroner Sprachaufzeichnung für Hausnummmerspeicherung. Bluetooth GPS-Logger habe ich, Handy müßte ich mir neu anschaffen. Ich besitze z. Z. noch kein Handy (78er Generation)und bräuchte wenn überhaupt nur eins, mit dem ich mal einen Notruf senden kann, falls mir in einer Bar das Geld ausgeht. Die Möglickeit Fotos in akzeptabler Auflösung zur Dokumentation sollten vielleicht nicht fehlen. Welche Empfehlungen können da von den Praktikern für Handytypen und aufspielbarer Software geben werden? Gruß Dieter Jasper ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Was macht OSM in Deutschland so erfolgreich?
Sven Geggus schrieb: Carsten Schwede computerte...@gmx.de wrote: Ich glaube das liegt zu einem großen Teil an der Schrebergartenmentalität. Jeder möchte sein Gebiet so schön wie möglich machen, eben besser oder mindestens genausogut wie der Gartennachbar. Das kann ich nur unterschreiben. Ich hatte mir für 2009 vorgenommen in meinem Heimatdorf jeden Feldweg zu erfassen. Ich bin fast fertig :) Du kommt aus einem Dorf das nur aus Feldwegen besteht? *Duck und weg* ;-) Bie mir ist es beides - Heimatort vollständig erfassen und eine gute Alternative zu den kommerziellen Navi zu bieten die auch Spezialanwendungen ermöglichen. Daneben schau ich auch immer in die weissen OSM Gegenden zu kommen um dort ein paar Beipieldaten (paar Strassen, Gebäude, POIs etc ) zu hinterlassen um dortigen Anfangswilligen den Einstieg zu erleichtern. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erfasst ihr Hausnummern?
Hallo Dieter, viel ist schon getan und es werden immer mehrAdressen getagt. Welche komfortablen Möglichkeiten mit erschwinglichen Geräten haben sich dafür bewährt. ich nehme mein Fahrrad und einen Garmin der den Weg aufzeichnet. Als Diktiergerät habe ich einen MP3-Player, in den ich während der Fahrt die Hausnummern spreche und pro Hausnummer gibts noch einen Wegpunkt. Die Eingabe erfolgt dann per JOSM, da wird dann Track und Sprachaufzeichnung synchonisiert und dann rein mit den Hausnummern. Gruß Kai ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Was macht OSM in Deutschland so erfolgreich?
Tirkon schrieb: UMAX974 umax...@googlemail.com wrote: Ich glaube das liegt zu einem großen Teil an der Schrebergartenmentalität. Jeder möchte sein Gebiet so schön wie möglich machen, eben besser oder mindestens genausogut wie der Gartennachbar. Wenn es wirklich daran liegt bin ich Falsch dabei. Mein Anfangsimpuls war Schlicht und Einfach: - die gekaufte NAVI Karte ist mir zu teuer - ich such nach einer Alternative - finde OSM - das was ich oft nutze kann ich selbst optimiern und kann von dem profitieren was andere optimiert haben. Ich bin begeistern von Karten sie so detailliert sind wie die um Stuttgart herum, und Freue mich wenn nicht nur ich, sondern andere um mich herum die Karte hier in der Gegend Stück für Stück so weit verbessern, dass ich bei meiner nächsten Tour Wege finde, die mit keinem anderen Navi in Deutschland oder sogar Weltweit zu finden wären. Dass ich sicher an Ziele in Ortschaften geführt werden, die ich mit keiner anderen Karte finden würde. Du hast natürlich recht damit, dass dies ein Argument für die Mitarbeit bei OSM ist. Dieses Argument gilt aber für den Bewohner eines jeden Staates. Es muss also ein bißchen mehr hinter den hiesigen Hängt wohl auch etwas mit der Bevölkerungsdichte und Verteilung zusammen. Deutschland ist relativ dicht mit Ballungszentren belegt. Flächen die nicht in 30 Minuten vom Rande einer mittleren bis grossen Stadt aus erreichbar sind gibt es schon relativ selten. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Was macht OSM in Deutschland so erfolgreich?
Carsten Schwede schrieb: Hallo, Tirkon schrieb: ... wegen der hohen Postingfrequenz in der Mailingliste? ... weil es viele Mapper gibt? ... weil der einzelne Mapper fleißig ist? ... weil der Mapper informiert ist ... wegen vieler Bots? ... wegen der vielen Hilfsprogramme und Fehlersuchaktionen? ... wegen solcher und ähnlicher Einzelaktionen?: Ich glaube das liegt zu einem großen Teil an der Schrebergartenmentalität. Jeder möchte sein Gebiet so schön wie möglich machen, eben besser oder mindestens genausogut wie der Gartennachbar. Ja, oder aber so wie ich eine möglichst dauerhafte Duftmarke setzen möchte, natürlich auch schön gestaltet. Als ich vor ca. 2 Jahren auf OSM stieß war mein Revier - das Emsland - noch weitgehend eine Schneelandschaft. Ich habe mir also überlegt wie kann ich eine langwirkende Duftmarke setzen und habe so bei meiner Kreistadt und nachfolgend bei den umliegenden größeren Ortschaften meine Reviermarkierungen gesetzt. Voller Stolz seh ich, dass auch noch heute zahlreiche ways meine Duftftmarke tragen. Anderseits habe ich dadurch vielleicht auch einige Mapper aufgeschreckt, schnell noch ihren Beitrag zu leisten bevor für sie vielleicht nur noch HKS (Hundekotspender) zu ergänzen sind. So sind wir Deutschen nun mal gestrickt, oderr irre ich vielleicht doch. Gruß Dieter Jasper (der eigentlich sonst ein ganz netter Mensch ist) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erfasst ihr Hausnummern?
Elchtreiber schrieb: Hallo Dieter, viel ist schon getan und es werden immer mehrAdressen getagt. Welche komfortablen Möglichkeiten mit erschwinglichen Geräten haben sich dafür bewährt. ich nehme mein Fahrrad und einen Garmin der den Weg aufzeichnet. Als Diktiergerät habe ich einen MP3-Player, in den ich während der Fahrt die Hausnummern spreche und pro Hausnummer gibts noch einen Wegpunkt. Und wie wird dann die Sprachaufzeichnung mit den Wegpunkten synchronisiert? Hat er MP3-Plsxer eine Zeitcode? Gruß Dieter Jasper Die Eingabe erfolgt dann per JOSM, da wird dann Track und Sprachaufzeichnung synchonisiert und dann rein mit den Hausnummern. Gruß Kai ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erfasst ihr Hausnummern?
Dieter Jasper schrieb: ich nehme mein Fahrrad und einen Garmin der den Weg aufzeichnet. Als Diktiergerät habe ich einen MP3-Player, in den ich während der Fahrt die Hausnummern spreche und pro Hausnummer gibts noch einen Wegpunkt. Und wie wird dann die Sprachaufzeichnung mit den Wegpunkten synchronisiert? Hat er MP3-Plsxer eine Zeitcode? Mein MP3-Player hat keinen Zeitcode, deswegen setze ich einen Synchronisierungs-Wegpunkt: Ich spreche Mark! ins Mikro uns erstelle gleichzeitig den Wegpunkt. In JOSM halte ich die Audioausgabe am Mark! an, und verschiebe den Zeiger auf den entsprechenden Wegpunkt. Voilà - synchronisiert. Das ist im Grunde das gleiche wie in der Hilfe [1] unter 1. beschrieben. Grüße, Michi [1] http://josm.openstreetmap.de/wiki/Help/AudioMapping/Synchronization signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Was macht OSM in Deutschland so erfolgreich?
Tirkon schrieb: Wir erleben es am Beispiel der deutschen Wikipedia, wo die derzeitig anstehende Entscheidung zur Inklusion/Exklusion fast zum Scheideweg zwischen Überleben und Sterben hochstilisiert wird. Warum nicht? Wenn ich dauernd erleben würde wenn jemand meine highway=residental in highway=road umtaggen würde oder meine Bushaltestellen rauslöschen würde oder, oder, oder. An solchen einem Punkt würde mir OSM schnell keinen Spaß mehr machen und dann wäre ich auch schnell weg. Und in dieser Situation ist die deutsche Wikipedia. In OSM haben wir das Glück das man weit in die Tiefe gehen kann ohne das sich die Frage nach der Relevanz stellen wird. Wenn es jemanden in meinem Gebiet geben würde der die Kanaldeckel samt Typ und Hersteller in OSM einträgt stört der nicht weiter, auch wenn es nur wenige geben dürfte für diese die Information von Nutzen sind, Wenn ich hingegen in Wikipedia reinschreibe .In C-Dorf gibt es 52 Bushaltestellen wird dieser Satz wohl nur geringe Überlebenschancen haben. Und wenn ich dann noch dazu schreibe das diese sich aus 82 Masten zusammensetzen, an 65 ein Papierkorb montiert ist und 34 mit einen Unterstand ausgestattet sind würde ich in WP zukünftig wohl einen schweren Stand haben. In OSM ist dieses Engagement positiv, weil die Menge an Informationen nicht stört. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Was macht OSM in Deutschland so erfolgreich?
Carsten Schwede schrieb: Ich glaube das liegt zu einem großen Teil an der Schrebergartenmentalität. Jeder möchte sein Gebiet so schön wie möglich machen, eben besser oder mindestens genausogut wie der Gartennachbar. Das war für mich sicherlich auch der ausschlaggebende Ansporn. Hat das Vorhandensein eines Rankings wie http://osm.gt.owl.de/Strassenliste/map-nordrhein-westfalen.html eigentlich Einfluß auf die Geschwindigkeit mit der die Vollständigkeit wächst? Zumindest lockt diese Karte scheinbar niemanden nach Erndtebrück, Eslohe, Breckerfeld oder Mettingen. Dort wo Mapper vorhanden sind ist es nach eigener Erfahrung durchaus ein Ansporn. A-Stadt hat nur 38%. Da müssen wir doch etwas machen. Oder wenn man nach B-Weiler, 27% fährt schaut man vorher noch in OSM und auf dem Weg dorthin nicht über bereits gemappte Straßen fahren zu müssen. Die belgischen Orte nahe der Grenze wachsen von D aus ins Landesinnere. Das sieht mir so aus, als ob die arbeitslosen Aachener Mapper jetzt nach Belgien ziehen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Was macht OSM in Deutschland so erfolgreich?
Am Sonntag 08 November 2009 01:45:28 schrieb Dieter Jasper: HKS (Hundekotspender) Ihr seid eklig, wo gibt es denn sowas? (Ich geh mal schnell Hondekot-*TÜTEN*-Spender mappen...) Gruß, Bernd, scnr. -- Spontaneität muß wohlüberlegt sein. 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
[Talk-de] Lizenz der OpenGeoDB
Hallo, hat jemand einen Link wo gesagt wird unter welcher Lizenz genau die OpenGeoDB steht? Weder deren Wiki, noch deren Download-Seite noch Google oder das Archiv dieser Mailing-Liste scheinen irgendwo deren Lizenz zu nennen. Nur das sie inkompatibel mit unserer ist. (Hier geht es darum lokal beide zu verwenden um Suchergebnisse zu verfeinern, nicht irgendwas in OSM einzupflegen.) Grüsse, Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erfasst ihr Hausnummern?
2009/11/8 Dieter Jasper dieter_jas...@web.de: 2. Walking Paper und Adressen grob auf dem Papierausdruck einzeichen und dann weiter verarbeiten. Funktioniert wunderbar. Vorher auf openstreetmap.org unter export die entsprechenden Regionen in einer etwas höheren Zoom-Stufe als man glaubt sie zu brauchen ausdrucken und fertig. So bleibt auch Platz für Notizen und man sieht genau was wir bereits haben. (z.B. gleich noch Fehlende Geschäfte, öffentliche Toiletten, Telephonzellen,...) Fehlende Wege (z.B. Fußwege quer durch den Block) oder Hausumrisse kann man dann auch gleich auf dem Papier einzeichnen. So ein halber Stadtteil ist in 30-60min gemacht. Das ist weniger Arbeit als man denkt. Photos sind für Hausnummern viel zu viel Arbeit, zumal man auch nicht weis in welche Richtung jetzt die Kamera geschaut hat. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummernimport, wie würdet ihrs mac hen?
2009/11/7 Robert S. osm-m...@autobahnen-europa.eu: 2009/11/7 Sven Geggus li...@fuchsschwanzdomain.de Hallo zusammen, ich habe einen Import von Hausnummern gemacht: http://osm.org/go/0JQWVejWS-- Nun sind die Hausnummern Nodes dort irgendwie immer so, dass sie quasi am Eingang des Hauses sind. Diese Information wollte ich nicht verlieren, deshalb habe ich Nodes importiert, statt dem zugehörigen Gebäude einfach die Nummern zu verpassen. Relationen zwischen Gebäude und Node sind im Hausnummernschema aber nicht vorgesehen. Einfach den Node in den Way des Gebäudes einfügen. Wenn du willst, kannst du dann eine building-Relation [1] erstellen. Dort den Hausumriss-way mit der Rolle outline und alle Eingansnodes (die mit der Adresse) mit der Rolle entrance einfügen. [1] http://wiki.openstreetmap.org/wiki/Relations/Proposed/Buildings Das wäre wohl der Königsweg. Nodes wären aber auf jeden Fall schonmal besser als gar keine Hausnummern. Steht dir außer den Hausnummern auch die Information zu welcher Strasse die jeweils gehören zur Verfügung? An den Eckhäusern ist das bei dir nicht eindeutig. Für welche Gegenden hast du Daten? Ansonsten, tolle Arbeit. Gruss, Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressen bei Eckgrundstücken
2009/11/7 Raimond Spekking raimond.spekk...@gmail.com: Dieter Jasper schrieb: Hallo, bei Eckgrundstücken und vielleicht auch anderen Fällen kommt es häufig vor, dass das Haus die Adresse Astraße hat, der Eingang aber an der Bstraße liegt. Für addr:street und addr:hausnr nehme ich in dem Fall immer die tatsächliche Post-Adresse. Um zusätzliche Angaben bzgl. entrance habe ich mich bisher noch nicht gekümmert. Gruss, Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Was macht OSM in Deutschland so erfolgreich?
Hallo, am 08.11.2009 06:42 schrieb Bernd Wurst: Am Sonntag 08 November 2009 01:45:28 schrieb Dieter Jasper: HKS (Hundekotspender) Ihr seid eklig, wo gibt es denn sowas? Oh, die gibts reichlich. Sind aber schlecht zu mappen, weil mobil. Kann man höchstens Aufenthaltswahrscheinlichkeiten eintragen. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Was macht OSM in Deutschland so erfolgreich?
On Sun, Nov 08, 2009 at 12:20:58AM +0100, Tirkon wrote: Wir erleben es am Beispiel der deutschen Wikipedia, wo die derzeitig anstehende Entscheidung zur Inklusion/Exklusion fast zum Scheideweg zwischen Überleben und Sterben hochstilisiert wird. Meinst du wir werden leute bekommen die Straßen oder Details loeschen weil die nicht relevant sind? SCNR Flo -- Florian Lohoff f...@rfc822.org Es ist ein grobes Missverständnis und eine Fehlwahrnehmung, dem Staat im Internet Zensur- und Überwachungsabsichten zu unterstellen. - - Bundesminister Dr. Wolfgang Schäuble -- 10. Juli in Berlin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Was macht OSM in Deutschland so erfolgreich?
On Sun, Nov 08, 2009 at 06:33:32AM +0100, Thomas Reincke wrote: Carsten Schwede schrieb: Ich glaube das liegt zu einem großen Teil an der Schrebergartenmentalität. Jeder möchte sein Gebiet so schön wie möglich machen, eben besser oder mindestens genausogut wie der Gartennachbar. Das war für mich sicherlich auch der ausschlaggebende Ansporn. Hat das Vorhandensein eines Rankings wie http://osm.gt.owl.de/Strassenliste/map-nordrhein-westfalen.html eigentlich Einfluß auf die Geschwindigkeit mit der die Vollständigkeit wächst? Zumindest lockt diese Karte scheinbar niemanden nach Erndtebrück, Eslohe, Breckerfeld oder Mettingen. Ich bin ja schon verrueckt wenn es nach meiner Frau und meinen Kollegen geht, aber irgendwo bei 50km ist auch mal schluss - Ich habe 2 kleine Kinder und kann nicht den ganzen Tag mich ins Auto setzen um die letzten 2 Straßen in Eslohe zu machen. Im Rahmen einer Mapping Party fuer ich da schon mal einen Sams oder Sonntag Opfern - Aber da muesste jemand vor Ort mal was Warmes mit Netzanbindung organisieren. Solange sich das mal hier 20 Minuten da eine Halbe in den Arbeitsweg einbauen laesst mache ich jeden Tag ein bischen. So ist halt im Laufe von 2 Jahren im umkreis von 20-30km alles vervollstaendigt worden. Das einzige was wirklich fehlt sind Adressen und ÖPNV - Bei Adressen habe ich nur die 3 Gemeinden die wirklich auf dem Arbeitsweg liegen vollstaendig. Aber ich habe noch 20 Einwohner in 3 Orten in der Naehe bei denen noch so gut wie keine Adresse vorhanden ist. Zu tun ist fuer die naechsten 5 Jahre noch genug. Flo -- Florian Lohoff f...@rfc822.org Es ist ein grobes Missverständnis und eine Fehlwahrnehmung, dem Staat im Internet Zensur- und Überwachungsabsichten zu unterstellen. - - Bundesminister Dr. Wolfgang Schäuble -- 10. Juli in Berlin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-it] orkut - Fabio Locati desidera che ti iscrivi a orkut.
Fabio Locati desidera che tu ti iscriva a orkut. Iscriviti subito! http://www.orkut.com/Join.aspx?id=4AF4DFB3FBE643B3mt=22 * * * Cosa puoi fare su orkut: - COMUNICA con amici e familiari usando scrap e messaggistica istantanea - TROVA nuove persone tramite amici di amici e community - CONDIVIDI video, immagini e passioni in un unico posto Centro assistenza: http://help.orkut.com/support/ * * * Casella di posta piena? Blocca l'invio di email da parte degli utenti orkut andando su: http://www.orkut.com/Block.aspx?mt=22 ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Sensi unici alternati,
Ho appena corretto a mente il corso del Bacchiglione sotto i ponti di debba, aggiungendo i tag per gli sbarramenti. Qualcuno puo' verifiare la cosa, visto che sono alle prime armi? Come forse avrai visto, specificando due rami del fiume hai in realtà creato un'area d'acqua. Ciò è corretto, ma ora è necessario inserire al suo interno un'isola (poligono con tag landuse=island). Anche se non so esattamente come funziona, l'isola deve essere membro di un multipoligono. Ti segnalo la pagina http://wiki.openstreetmap.org/wiki/Relations/Multipolygon al riguardo. Alessandro Pozzato ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Riserve naturali e linea di costa
Ciao a tutti, ho caricato le riserve naturali del FVG e ho un problema con questa area: http://osm.org/go/0IMiPdN la riserva prende sia un po' di terra che di mare e la linea di costa è completamente nascosta! che dite: ho sbagliato qualcosa io oppure è meglio che segnali la cosa a chi gestisce lo stile di mapnik (magari rendendo l'area trasparente come accade per i parchi)? Ciao, Stefano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Riserve naturali e linea di costa
Ciao stefano, prova a contattare quelli di mapnik, ma come sempre dipende da chi trovi a risponderti un esempio http://trac.openstreetmap.org/ticket/2409 :-( --- - Original Message - From: Stefano Salvador stefano.salva...@gmail.com To: openstreetmap list - italiano talk-it@openstreetmap.org Sent: Saturday, November 07, 2009 4:03 PM Subject: [Talk-it] Riserve naturali e linea di costa Ciao a tutti, ho caricato le riserve naturali del FVG e ho un problema con questa area: http://osm.org/go/0IMiPdN la riserva prende sia un po' di terra che di mare e la linea di costa è completamente nascosta! che dite: ho sbagliato qualcosa io oppure è meglio che segnali la cosa a chi gestisce lo stile di mapnik (magari rendendo l'area trasparente come accade per i parchi)? Ciao, Stefano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-at] Verschenke Garmin eTrex H
Aalfang-Heidenreichstein fehlt, und die anderen Strecken sind glaube ich nur Einspielungen von plan.at - also sicher verbesserungswürdig. Weihnachten/Sylvester gibt es nach meinem Wissen Fahrten, sonst erst wieder im Frühling. Setze dich in Verbindung mit Urban von der erlebnisbahn.at. Werner Macho schrieb: Also das mit den Schmalspurbahnen lässt sich machen - ich bin da oben öfter mal unterwegs .. Mal schauen wann wieder ein Zug fährt und ich bin mit von der Partie .. Würde dir das reichen? Welche meinst du eigentlich? Gmünd-Litschau oder Gmünd-Groß-Gerungs? Oder beide? Gibts da noch mehr? lg Werner Michael Pichler schrieb: Kannst Du das den Waldviertler Schmalspurbahnen borgen, damit die ihre Strecken aufzeichnen? Ich habe denen kürzlich geschrieben, ob sie eine Aufzeichnung ihrer Strecken haben --- haben sie leider nicht. Michael ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-ca] [Imports] canvec-to-osm 0.9.6 now available
Sam Vekemans wrote: Im not making a new script, the folks who understand python, are making a script that can solve the 'duplicate intersecting nodes' and 'inner/outer relation' problem. (Yes you might have fixed it, but i've reached the crux of my technical ability) Sure, they can use java, if that works for them. Im just isolating my canvec-to-osm script to handle the 80 map features that i know converts correctly. The other 10 can be dealt with using another option. Since i dont know how to program (accept in basic DOS) im not that much help. Others who are experienced in python java are welcome to take the lead. Frank already started to help out maptastically :) Sam On 11/6/09, Ian Dees ian.d...@gmail.com wrote: On Nov 6, 2009, at 9:28 PM, Sam Vekemans acrosscanadatra...@gmail.com wrote: This python script is yet to be made 'canvec2osm.py' its open to anyone to make, and i recommend that who ever does, its ONLY 1 person who is in charge of maintaining the script. Why are you creating another shp to osm converter? Is there something the existing tools don't do? I thought you were using shp-to-osm? What changed? Hi Sam, The idea what I mentioned is to convert your batch files to Python. The main reason for that is that this way people using Linux or other OSs can also perform this conversion locally. I know you want to convert all of Canada yourself, but that is still a lot of work. Many hands make light work. The only thing we should be concerned about is that we're all using the same rule file. This is the most vital part in ensuring consistency across the country. To Ian: shp-to-osm won't disappear in the process. Sam's batch files are still calling it. It would be pointless to create a second version. There is already a Python script with the same name, but it was written specifically for the MassGIS import. Sam, can you give some additional clarification what your intentions are? I'm afraid I'm not following them well. When you mentioning removing duplicate nodes and relations, it looks as if you intend to create a script which does some post-processing. Is that correct? I haven't started anything in that area. (I actually still need to start with the Python version of your batch script, but I'm going to work on that today.) Now we're talking on this: in shp-to-osm (Java) tags are now put properly on the multipolygon relationship. They also still appear on the inner polygons (mentioned to Ian already), but that should be fixed. Since shp-to-osm is called for one feature type at a time, there are some new challenges when multiple feature types are involved. I guess you've been thinking about that already. Duplicate nodes will become an issue when you have for example a residential area with an adjacent wooded area (assuming that the boundaries are matching exactly). It will be difficult to deal with this. I'm not sure if it would be technically possible to adjust shp-to-osm for that, but the result will be that the files will become huge. They already have to be split up for certain feature types, and I don't think it is possible to use the same set of IDs over multiple output files. From what I understand about the upload process (and someone please correct me if this isn't right), the OSM server will return new ID numbers for any nodes, ways, and relationships uploaded. In the OSM files generated by Ian, and also when you're editing in JOSM yourself, temporary IDs are assigned. They have a negative value, which indicates that these objects don't exist on the server. So, this means that, after you have uploaded file00.osm, and you open file01.osm, JOSM or the server do no longer remember to what objects any IDs are _referring_ to, if those objects are not _defined_ in the same file. The same issue is going on with multipolygon relationships, where a part of the ways are reused. This can only happen if everything is defined in the same file. And such a file will be way too large to upload safely to the server. Recently I noticed that if you want to create/update/delete about 10k objects the server is going to act difficult. Regarding relationships, and reuse of the geometry: I think that we have not only to remove duplicate nodes, but also split up ways, otherwise the JOSM validator will complain about overlapping ways. A way can be used in multiple relationships. A third thing which might need to be resolved are map features which cross the boundary of the NTS tiles. Do we want to merge them? If these features have the same Geobase metadata (ID, etc.), then it shouldn't be a big problem, otherwise we need to decide whether we prefer to keep the metadata, or if we want to have merged features. All of this means we can't do anything to clean up the data. Sure we can, but this can only be done after an initial upload to the server. That way we can still apply any logic to deal with
Re: [Talk-ca] [Imports] canvec-to-osm 0.9.6 now available
Hi Ian, Ian Dees wrote: On Sat, Nov 7, 2009 at 8:59 AM, Frank Steggink stegg...@steggink.org mailto:stegg...@steggink.org wrote: Sam, can you give some additional clarification what your intentions are? I'm afraid I'm not following them well. When you mentioning removing duplicate nodes and relations, it looks as if you intend to create a script which does some post-processing. Is that correct? I haven't started anything in that area. (I actually still need to start with the Python version of your batch script, but I'm going to work on that today.) Are these duplicate nodes/relations being created by the converter or are they in the source data? I'm talking mostly from my experience with Geobase. When roads are imported, where there is already data from an adjacent tiles, nodes get duplicated. This also happens when I copy over Geobase data multiple times. I'm not sure how this works out for the Canvec data, because there are already multiple files. However, if features in multiple files are touching each other, their nodes will be identified as duplicates. This is also true for adjacent NTS tiles. The problem with shp-to-osm which I found earlier this week has already been fixed :) Now we're talking on this: in shp-to-osm (Java) tags are now put properly on the multipolygon relationship. They also still appear on the inner polygons (mentioned to Ian already), but that should be fixed. Tags appears on the inner ways because you have an inner rule in the rules.txt file. If you remove those lines from the rules.txt, you should end up with no tags on inner ways of multipolygons. If this doesn't happen, then it's a bug and I will fix it. OK, that could explain why this is happening. I'll look at it, and share my observations. Since shp-to-osm is called for one feature type at a time, there are some new challenges when multiple feature types are involved. I guess you've been thinking about that already. Duplicate nodes will become an issue when you have for example a residential area with an adjacent wooded area (assuming that the boundaries are matching exactly). It will be difficult to deal with this. I'm not sure if it would be technically possible to adjust shp-to-osm for that, but the result will be that the files will become huge. They already have to be split up for certain feature types, and I don't think it is possible to use the same set of IDs over multiple output files. I do have a relationificator plugin started for shp-to-osm that will attempt to solve this problem by converting exactly-overlapping edges into relations and delete duplicate primitives. If there's a strong need for it I can continue to work on it. That sounds very interesting. I guess this only works within the single shape file which is being converted, correct? What is the behavior if a file has to be split up, because it becomes too large? From what I understand about the upload process (and someone please correct me if this isn't right), the OSM server will return new ID numbers for any nodes, ways, and relationships uploaded. In the OSM files generated by Ian, and also when you're editing in JOSM yourself, temporary IDs are assigned. They have a negative value, which indicates that these objects don't exist on the server. So, this means that, after you have uploaded file00.osm, and you open file01.osm, JOSM or the server do no longer remember to what objects any IDs are _referring_ to, if those objects are not _defined_ in the same file. The same issue is going on with multipolygon relationships, where a part of the ways are reused. This can only happen if everything is defined in the same file. And such a file will be way too large to upload safely to the server. Recently I noticed that if you want to create/update/delete about 10k objects the server is going to act difficult. I normally upload my NHD changesets with 40k-50k changes in each upload without problem. It takes an hour or so to apply (depending on server load), but it works without error. What program are you using for the upload? Is it bulk-upload, JOSM, or something else? I'm using JOSM, because I had problems with bulk-upload. If there is something better and more robust (the upload with JOSM fails when there are about 10k changes), I would certainly give it a try. Regarding relationships, and reuse of the geometry: I think that we have not only to remove duplicate nodes, but also split up ways, otherwise the JOSM validator will complain about overlapping ways. A way can be used in multiple relationships. This would also happen with the relationificator. A third thing which might need to be resolved are map features which cross the boundary of the NTS tiles. Do we want to merge them?
Re: [Talk-ca] [Imports] canvec-to-osm 0.9.6 now available
Ian Dees wrote: I normally upload my NHD changesets with 40k-50k changes in each upload without problem. It takes an hour or so to apply (depending on server load), but it works without error. What program are you using for the upload? Is it bulk-upload, JOSM, or something else? I'm using JOSM, because I had problems with bulk-upload. If there is something better and more robust (the upload with JOSM fails when there are about 10k changes), I would certainly give it a try. I use JOSM -- I check upload as one changeset and check close changeset after upload. I usually try to do this when the load on the database and ruby workers are low. OK thanks. I've seen this option, and I've only tried it once. This was with a small upload only. I did not think of trying it with a large changeset. Regarding the inner rules: I've just checked it, and this is working as you mentioned. Great :) I also tried the -t option, with comparison on file level, and any ways used in a relation are being kept. As far as I'm concerned, this version of shp-to-osm is good to go, if we're not going to deal with any of the additional issues we discussed this morning. Great job Ian! Frank ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] [Imports] canvec-to-osm 0.9.6 now available
On Sat, Nov 7, 2009 at 9:56 AM, Frank Steggink stegg...@steggink.orgwrote: I do have a relationificator plugin started for shp-to-osm that will attempt to solve this problem by converting exactly-overlapping edges into relations and delete duplicate primitives. If there's a strong need for it I can continue to work on it. That sounds very interesting. I guess this only works within the single shape file which is being converted, correct? What is the behavior if a file has to be split up, because it becomes too large? As with the shp-to-osm glomming plugin, the entire shapefile will be read into memory, the plugin will be run on it, and then the split-up OSM files will be written out. Thus, you should not have to worry about primitives crossing file boundaries. I normally upload my NHD changesets with 40k-50k changes in each upload without problem. It takes an hour or so to apply (depending on server load), but it works without error. What program are you using for the upload? Is it bulk-upload, JOSM, or something else? I'm using JOSM, because I had problems with bulk-upload. If there is something better and more robust (the upload with JOSM fails when there are about 10k changes), I would certainly give it a try. I use JOSM -- I check upload as one changeset and check close changeset after upload. I usually try to do this when the load on the database and ruby workers are low. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] [Imports] canvec-to-osm 0.9.6 now available
On Nov 6, 2009, at 9:28 PM, Sam Vekemans acrosscanadatra...@gmail.com wrote: This python script is yet to be made 'canvec2osm.py' its open to anyone to make, and i recommend that who ever does, its ONLY 1 person who is in charge of maintaining the script. Why are you creating another shp to osm converter? Is there something the existing tools don't do? I thought you were using shp-to-osm? What changed? ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] [Imports] canvec-to-osm 0.9.6 now available
On Sat, Nov 7, 2009 at 9:48 AM, James A. Treacy tre...@debian.org wrote: There are cases where the same way exists in different data sets but with different uses. A good example is that islands in the waterbody data are often repeated in the wooded data (if the island happens to be wooded, which happens a lot). Importing one set after another leads to duplicated ways. This case is time consuming to fix because you have to reconcile two ways and a relation. This same issue arises with wetlands. Probably others too but these are the ones I've encountered most often. This is the desired effect. Technically there should be one multipolygon defining the waterway (or lake) and another multipolygon for the wooded area (with separate ways? or maybe the wooded area's outer way should be the lake's inner way?). Keep in mind that removing duplicate nodes/ways in all cases is bad ... in some cases there actually are two features at the exact same point. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] [Imports] canvec-to-osm 0.9.6 now available
On Sat, Nov 7, 2009 at 8:59 AM, Frank Steggink stegg...@steggink.orgwrote: Sam, can you give some additional clarification what your intentions are? I'm afraid I'm not following them well. When you mentioning removing duplicate nodes and relations, it looks as if you intend to create a script which does some post-processing. Is that correct? I haven't started anything in that area. (I actually still need to start with the Python version of your batch script, but I'm going to work on that today.) Are these duplicate nodes/relations being created by the converter or are they in the source data? Now we're talking on this: in shp-to-osm (Java) tags are now put properly on the multipolygon relationship. They also still appear on the inner polygons (mentioned to Ian already), but that should be fixed. Tags appears on the inner ways because you have an inner rule in the rules.txt file. If you remove those lines from the rules.txt, you should end up with no tags on inner ways of multipolygons. If this doesn't happen, then it's a bug and I will fix it. Since shp-to-osm is called for one feature type at a time, there are some new challenges when multiple feature types are involved. I guess you've been thinking about that already. Duplicate nodes will become an issue when you have for example a residential area with an adjacent wooded area (assuming that the boundaries are matching exactly). It will be difficult to deal with this. I'm not sure if it would be technically possible to adjust shp-to-osm for that, but the result will be that the files will become huge. They already have to be split up for certain feature types, and I don't think it is possible to use the same set of IDs over multiple output files. I do have a relationificator plugin started for shp-to-osm that will attempt to solve this problem by converting exactly-overlapping edges into relations and delete duplicate primitives. If there's a strong need for it I can continue to work on it. From what I understand about the upload process (and someone please correct me if this isn't right), the OSM server will return new ID numbers for any nodes, ways, and relationships uploaded. In the OSM files generated by Ian, and also when you're editing in JOSM yourself, temporary IDs are assigned. They have a negative value, which indicates that these objects don't exist on the server. So, this means that, after you have uploaded file00.osm, and you open file01.osm, JOSM or the server do no longer remember to what objects any IDs are _referring_ to, if those objects are not _defined_ in the same file. The same issue is going on with multipolygon relationships, where a part of the ways are reused. This can only happen if everything is defined in the same file. And such a file will be way too large to upload safely to the server. Recently I noticed that if you want to create/update/delete about 10k objects the server is going to act difficult. I normally upload my NHD changesets with 40k-50k changes in each upload without problem. It takes an hour or so to apply (depending on server load), but it works without error. Regarding relationships, and reuse of the geometry: I think that we have not only to remove duplicate nodes, but also split up ways, otherwise the JOSM validator will complain about overlapping ways. A way can be used in multiple relationships. This would also happen with the relationificator. A third thing which might need to be resolved are map features which cross the boundary of the NTS tiles. Do we want to merge them? If these features have the same Geobase metadata (ID, etc.), then it shouldn't be a big problem, otherwise we need to decide whether we prefer to keep the metadata, or if we want to have merged features. All of this means we can't do anything to clean up the data. Sure we can, but this can only be done after an initial upload to the server. That way we can still apply any logic to deal with duplicate nodes, reuse of features in multiple relationships, and merging features. The script will have to work live on the server: download an area, do the cleanup, and upload. In such case I think it would be the safest (and required!) that the script only does the download and the cleanup, and that a human verifies the result before upload. If we're implementing such cleanup, it needs to be executed as soon as possible after the upload, because sometimes users are very quick to make changes to freshly uploaded data. It's relatively dangerous to upload these dirty OSM files to the server and the apply changes later. If someone makes a change to a single node in your data, then you suddenly can't make that automated change. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] [Imports] canvec-to-osm 0.9.6 now available
On Sat, Nov 7, 2009 at 9:59 AM, James A. Treacy tre...@debian.org wrote: On Sat, Nov 07, 2009 at 09:14:58AM -0600, Ian Dees wrote: Tags appears on the inner ways because you have an inner rule in the rules.txt file. If you remove those lines from the rules.txt, you should end up with no tags on inner ways of multipolygons. If this doesn't happen, then it's a bug and I will fix it. When you say 'no tags' do you really mean zero? What about when (as in our case) the source data requires attribution tags. Is it ok to duplicate those on the inner way? Without them it is not clear where the data came from. I was just pointing out why there are inner tags when you run shp-to-osm. Whether or not you want those tags to be there is another question. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] [Imports] canvec-to-osm 0.9.6 now available
On Sat, Nov 07, 2009 at 11:10:59AM -0500, Frank Steggink wrote: This actually means that the NTS tiles are too big to handle all at once. Maybe we should decide to use smaller working areas, by splitting up the NTS tiles in 4 x 4 subtiles. A disadvantage is that features will have to be split up (if this can be done automatically), or they have to be duplicated in the subtiles. Is there a reason that features crossing a tile boundary need to be split? If not, then features that cross the right or top edge can be left out and they will be included in the adjacent tile. There are some exceptional cases, for example features that cross an entire tile, but there are ways of dealing with them if this is ever implemented. -- James Treacy tre...@debian.org ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] [OSM Sherbrooke discussion] Re: Geobase / Canvec import workshop in Sherbrooke?
Hi Frank, Yves and all, I like the idea to have a mapping party in Sherbrooke that may attract people of other regions. The mapping party, considering we are in November, could concentrate on importing CanVec data for OSM. So, a Mapping Party with no field work, only desktop work in front of a fireplace. We would need a place in Sherbrooke with good wireless connections, good coffees and a room where we can talk and help each other. I think that La Brulerie on Wellington meets all the requirements. In order to make the event possible we will need experts that could explain importing tools (python, java, fme) and editing tools (josm, potlatch). Any volunteers ? Also, we need available data to import. My preference would be to have data that include all the CanVec feature classes. At my knowledge, I don't think such data can be generated rigth now. There are tools in development to generate such data but are not ready for importation. We (Daniel and I) do plan to work on a FME CanVec Import tool this winter but the tool won't be available in short terms. If we have Canvec OSM file ready to import, I will participate to organize the Sherbrooke Couch Mapping Party. Here are some ideas for the agenda: - Explain translation between CanVec features and OSM tags - Training on Importing tools - Explain OSM xml file - Training on JOSM - Importing session. Each participant take a region and import data. Let me know if anyone would like to participate at such event. We will keep on discussing to put in place the missing pieces. Cheers, Michel 2009/11/6 Frank Steggink stegg...@steggink.org Yves Moisan wrote: Hi Frank, Sorry for top posting, but I just want the ball rolling on the OSM Sherbrooke list. Michel was thinking of a Sherbrooke OSM meeting end November. I think the training you are proposing could be part of that meeting, although it is probably a bit technical for the average mapper. Michel, what do you think ? Yves Hi guys, I just had an idea, but because I don't know if it is a good one, I'll share it with you. Would it be a good idea to organize a workshop to import Geobase and Canvec data? Today I was contacted by Oxalin, who has been editing in Granby lately, and he mentioned that he and a friend are willing to help with the import as well (at least for St-Jean-sur-Richelieu). Perhaps there are also some people from Montreal interested. There is a large concentration of users in Sherbrooke, and because it is somewhat in between Montreal and Quebec, I think it would be the most obvious location. Regarding the workshop: I could explain how to import the roads, and edit / make connections with JOSM. We could also discuss the import of Canvec and NHN (hydro) data, because both Daniel and I are interested in it. Maybe Michel can explain how he imported the data through FME, although I'm not sure if this is relevant, because not everyone has access to it. About NHN import: I think that users from the Montreal area should also pick up the gauntlet. There is a whole lot of data to be imported. I also have no idea about the current data quality, but I expect this to be a huge undertaking. (And what I've done so far pales in comparison with that.) Anyways, they'll also benefit from OSM :) If you think this would be a good idea, what would be the term to organize such an event? A couple of hours, together with a small mapping party (proposal: gathering and entering addresses) should be enough. And of course a dinner at the end of the day :) For me it won't be a problem to come from Quebec, but I would prefer doing this before the winter really sets in. The winter is too cold and snowy to venture outdoors anyways, so what would be better than to spend our time importing data in our beloved Open Street Map? Cheers, Frank Hi Yves, What kind of meeting are you considering? Is it a mapping party, or just an event planned in an evening. In the latter case it won't be possible for me to attend, because of the distance. When the idea is to hold a mapping party (on a day in the weekend), I think it can be combined very well. For example, we could start an hour earlier in the morning, and I can explain a number of things about the import. The mapping party itself could start afterwards, so then people who do not care about the import, don't have to hear all of this stuff. I only mentioned a couple of hours because I was not aware you were thinking about organizing something yourself, and someone from farther away would not come if there was not a mapping party or something else going on. Right now the import of Geobase and Canvec data in Quebec is gaining momentum, so this is an excellent occasion to get more people jumping in :) Daniel already mentioned that he and Michel were interested in adding Canvec data around Sherbrooke (although I hope they're willing to extend their efforts to the rest of
Re: [Talk-ca] [OSM Sherbrooke discussion] Re: Geobase / Canvec import workshop in Sherbrooke?
Cool, thanks for the clarification. And yuppee! You understood! That would be great if you could maintain that 'portal' batch script :) just say the programs i need to install and the buttons to press, ...so i can sit back watch the batch do its 'magic'. The technical editing (scripting) just needs to be done by 1 person (at a time) but we all know that :) fyi, im now working 4 night shifts a week (mainly because my part of the conversion script is just about done) :) ... And i can start planning for my trip Across Canada next year! :-) actually it'll be in the next few days, but im giving it longer, so i can 'cleanup' my own script. (sams_babel-to-english.exe') cheers, Sam On 11/7/09, Frank Steggink stegg...@steggink.org wrote: Hi Sam, Waiting for Nov. 21st isn't a problem. The idea I had to discuss the conversion (both Geobase and Canvec) is still fresh, and we haven't set a date yet, nor settled on the details. Since I have a bit of experience with the Geobase conversion (with the new method to copy over data), and especially with the cleaning up part, I want to share it. That way others might benefit from it, and help us getting it all done. It would also be a good occasion to discuss / demonstrate the Canvec import for our region (roughly NTS tiles 021E and 021L). Michel has already thought about this more. Regarding the conversion script: which script are you talking about? Earlier this week I mentioned I wanted to rewrite your batch files (which call Ian's shp-to-osm) to Python, so they can be used on other OS's, and hopefully they'll also be easier to maintain. That's all. I haven't given other aspects much thought, before my e-mail this morning. I won't be available as the maintainer for such a script for a number of reasons, so I'll only do the port of your batch files. Hopefully this is clear now. By the way, instead of working on the Python-version of your batch files, I imported some Geobase data. Just one sheet left, and I'll put it on hold for a while (although that remains to be seen ;) ). Frank Sam Vekemans wrote: Hi, Would you be able to hold out until nov 21st? At that time, myself will have the shp-to-osm java script out of beta, and available to 'build-from' using python/java FME tools. Frank has offered to be the main person to maintain the conversion script once im done with it. And Yes, i agree, the actual act of importing the .osm files (made by the scripts) can be done with a 'couch mapping party' Cheers, Sam On 11/7/09, Michel Gilbert michc...@gmail.com wrote: Hi Frank, Yves and all, I like the idea to have a mapping party in Sherbrooke that may attract people of other regions. The mapping party, considering we are in November, could concentrate on importing CanVec data for OSM. So, a Mapping Party with no field work, only desktop work in front of a fireplace. We would need a place in Sherbrooke with good wireless connections, good coffees and a room where we can talk and help each other. I think that La Brulerie on Wellington meets all the requirements. In order to make the event possible we will need experts that could explain importing tools (python, java, fme) and editing tools (josm, potlatch). Any volunteers ? Also, we need available data to import. My preference would be to have data that include all the CanVec feature classes. At my knowledge, I don't think such data can be generated rigth now. There are tools in development to generate such data but are not ready for importation. We (Daniel and I) do plan to work on a FME CanVec Import tool this winter but the tool won't be available in short terms. If we have Canvec OSM file ready to import, I will participate to organize the Sherbrooke Couch Mapping Party. Here are some ideas for the agenda: - Explain translation between CanVec features and OSM tags - Training on Importing tools - Explain OSM xml file - Training on JOSM - Importing session. Each participant take a region and import data. Let me know if anyone would like to participate at such event. We will keep on discussing to put in place the missing pieces. Cheers, Michel -- Twitter: @Acrosscanada Blog: http://Acrosscanadatrails.blogspot.com Facebook: http://www.facebook.com/sam.vekemans OpenStreetMap IRC: http://irc.openstreetmap.org @Acrosscanadatrails ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-cz] automaticka pojmenovavacka ulic
On Fri 2008-11-21 16:36:47, Tom?? Tich? wrote:
Ahoj,
neda?? se mi p?elo?it nameit - v SVN je n?jak? divn? verze libosm, na
kterou nejde aplikovat Tv?j patch, ani to s n? nejde p?elo?it. Ne?lo
by n?kam vystavit verzi libosm, se kterou to funguje ?
Je to jeste aktualni? Kdyztak osobne, at na to zase nezapomenu...
On Sun, Aug 31, 2008 at 00:51, Pavel Machek pa...@ucw.cz wrote:
...docela funguje, tj na uz pojmenovanych ulicich se vetsinou
trefi. Prvni verse je tady.
(Samozrejme ocekava uid-adr adresni body jiz importovane... Coz se da
pro lokalni pouziti udelat treba tou shellovou priserou, pak download
zbytku v josm a ulozenim.)
Index: applications/lib/libosm/Way.cpp
===
--- applications/lib/libosm/Way.cpp (revision 10302)
+++ applications/lib/libosm/Way.cpp (working copy)
@@ -65,7 +65,7 @@
if (hasTags() || segments.size()) {
strmway id=' id ' endl;
for(int count=0; countsegments.size(); count++)
- strm seg id=' segments[count]
'/ endl;
+ strm nd id=' segments[count] '/
endl;
tagsToXML(strm);
strm/way endl;
} else {
Index: applications/lib/libosm/Parser.cpp
===
--- applications/lib/libosm/Parser.cpp (revision 10302)
+++ applications/lib/libosm/Parser.cpp (working copy)
@@ -45,23 +45,6 @@
}
- else if(!strcmp(element,segment))
- {
- curID=0;
- inSegment = true;
- for(int count=0; attrs[count]; count+=2)
- {
- if(!strcmp(attrs[count],from))
- from = atoi(attrs[count+1]);
- if(!strcmp(attrs[count],to))
- to = atoi(attrs[count+1]);
- if(!strcmp(attrs[count],id))
- curID = atoi(attrs[count+1]);
- }
-
- curObject = new Segment(curID,from,to);
- components-addSegment ((Segment*)curObject);
- }
else if (!strcmp(element,way))
{
curID=0;
@@ -74,13 +57,13 @@
curObject = new Way(curID);
components-addWay((Way*)curObject);
}
- else if (!strcmp(element,seg) (inWay))
+ else if (!strcmp(element,nd) (inWay))
{
int segID;
for(int count=0; attrs[count]; count+=2)
{
- if(!strcmp(attrs[count],id))
+ if(!strcmp(attrs[count],ref))
{
segID=atoi(attrs[count+1]);
((Way*)curObject)-addSegment(segID);
Index: applications/lib/libosm/Makefile
===
--- applications/lib/libosm/Makefile(revision 10302)
+++ applications/lib/libosm/Makefile(working copy)
@@ -3,6 +3,7 @@
OBJ = Object.o Way.o Parser.o Components.o functions.o llgr.o
FeaturesParser.o
NETOBJ = Client.o
TESTOBJ = test.o
+NAMEITOBJ = nameit.o
RULESTESTOBJ = rulestest.o
CXX = g++
@@ -15,6 +16,9 @@
test: $(TESTOBJ) libosm.a libosmnet.a
$(CXX) -o test $(TESTOBJ) libosm.a libosmnet.a $(LDFLAGS)
+nameit: $(NAMEITOBJ) libosm.a libosmnet.a
+ $(CXX) -o nameit $(NAMEITOBJ) libosm.a libosmnet.a $(LDFLAGS)
+
rulestest: $(RULESTESTOBJ) libosm.a
$(CXX) -o rulestest $(RULESTESTOBJ) libosm.a $(LDFLAGS)
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] vazby?
On Wed 2009-11-04 13:43:26, Petr Nejedl?? wrote: Pavel Machek napsal(a): On Tue 2009-11-03 18:46:02, Martin Mares wrote: Dobry vecer vespolek! A to ma chudinka navigace pokazdy stahovat celej svet aby zjistila ve ktery je zemi? Neni spis chyba, pokud si nemuze jednoduse stahnout vsechny relace, ve kterych objekty z daneho uzemi lezi? To co se tu navrhuje ale nejsou relace, nybrz polygon okolo. Ne ne, to nebude fungovat. Takze jo, predstavuju si, ze u kazdy ulice bude is_in=jmeno_mesta a u kazdyho mesta pak bude is_in=CR . Prijde mi hloupe udrzovat v mape informace, ktere jsou z principu redundantni -- pokud je prislusnost k mestu definovana jako lezeni uvnitr hranice mesta, ma byt reprezentovana tou hranici, ne nejakymi odvozenymi atributy. Ty se preci mohou kdykoliv dopocitat podle potreby. Trochu hloupe to je, ale zase nemusi kazdy implementovat vypocet znova (coz by bylo taky ne-chytre). 'Kdykoliv dopocitat' bohuzel neni vubec trivialni -- presne pro to ze tu hranicii vubec nemusim mit ve stazenych datech. Navic veci jako navit funguji offline a konveruji mezi ruznymi formaty... A specialne pro offline navigaci s konverzi formatu tam ty atributy nejsou potreba. Konverzni algoritmus ma dost casu a prenosovky na to, aby si stahnul tu (napr.) Ceskou Republiku celou a dopocital si to v 'dost prenosovky'? Nevim, tahat 170MB zbytecne mi prijde divny. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] vazby?
On Wed 2009-11-04 14:43:14, Martin Mares wrote: Ahoj! Neni spis chyba, pokud si nemuze jednoduse stahnout vsechny relace, ve kterych objekty z daneho uzemi lezi? To co se tu navrhuje ale nejsou relace, nybrz polygon okolo. A nestacilo by, aby protokol umel stahnout vsechny polygony, ktere maji s danym uzemim neprazdny prunik? Stacilo, ale on to AFAIK neumi. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
