Re: [Talk-transit] Bus route relation finished. Do you have comments for it? relation/29780
Hi Niklas, Signomi for the nodes I moved. I tossed away that useless mouse... Were you able to look at the bus route relations running through my home town? Cheers, Jo 2012/4/16 Niklas Cholmkvist towards...@gmail.com Jo winfi...@gmail.com wrote: Something odd is going on with this one: http://www.openstreetmap.org/browse/node/1673963816/history Except the relation addition some nodes also moved away from their original positions. Like node 163331760, 163331759 and maybe more. Anyway I thank you for your input. After reverting your changes (except the relation and the changes that you intended to do) if you wish please show me some bus routes that you have mapped so I can look at them and get ideas. Only if you want to. Cheers and have fun! ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-vi] Talk-vi Digest, Vol 10, Issue 1
Ngày 2012-04-18 4:05 AM, Lê Thanh viết: Chao anh Minh anh co the gui lai bang tieng Viet khong dau duoc khong? Thu anh gui bi loi, khong doc duoc. Thanh Chao cac ban, Toi da xay dung lai trang dau tieng Viet tai OpenStreetMap Wiki. [1] Trang nay co khung ban do thay doi hang ngay. Bay gio chi co Ha Noi, TPHCM, va Viet Nam thay phien; neu co vung khac o Viet Nam co nhieu chi tiet tren OpenStreetMap, xin cho toi biet. Toi cung muon giup xay dung trang openstreetmap.vn. [2] Cac ban co biet ai la nguoi chu cua trang do khong? Hien nay no chi co lien ket den mot vai trang cua cong dong nhung khong co cach xem ban do hoac loi gioi thieu du an. Co le trang do co the nhung' ban do the gioi tieng Viet do Wikimedia Toolserver cung cap. [3] (Ban do do ket hoa cac the name:vi o khap the gioi, bao gom cac ten Han-Việt tai Trung Quoc.) [1] http://wiki.openstreetmap.org/wiki/Vi:Main_Page [2] http://www.openstreetmap.vn/ [3] http://toolserver.org/~osm/locale/vi.html -- Nguyen Xuan Minh m...@1ec5.org Jabber: m...@1ec5.org; Blog: http://notes.1ec5.org/ ___ Talk-vi mailing list Talk-vi@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-vi
Re: [Talk-hr] Fwd: OrbView-3 is public domain
On 01/16/2012 11:37 PM, hbogner wrote: Sirove snimke se nalaze na http://data.osm-hr.org/orbview-3/ Sortirano po naoblaci, nemorate se brinut, bit će stalno online tako da nemorate odmah sve skinut, uzmite dio za testiranje prvo. Dio snimki na usgs stranicama je obrađen i sad je jednostavnije za rukovanje s njima. Trenutno završavam skidanje 82 snimke sa 0-10% naoblake, zatim sljedi slaganje i rezanje pa slanje na tms server. Prve 3 snimke su već gore, zoom lvl 10-16, 17 i 18 upload ide sporije ipak sam na dsl-u. ... lvl15: 1,149 items, totalling 39.1 MB lvl16: 4,387 items, totalling 141.3 MB lvl17: 16,896 items, totalling 453.5 MB lvl18: 66,180 items, totalling 958.9 MB total: 89,117 items, totalling 1.6 GB Čisto da vidite omjere, ovo je za 3 satelitske snimke. Treba probati za svaku snimku prilagoditi offset prije rezanja. Pozdrav ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
[Talk-hr] dors/cluc 2012
Jel netko planira kakvo predavanje? Ako ne imate kakvu ideju što bi htjeli da se prezentira pa da organiziramo nešto, ako još nije kasno za prijavu. ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
Re: [OSM-talk-be] Tagging Questions
Sander Deryckere wrote: Op 17 april 2012 12:40 schreef Marc Gemis marc.ge...@gmail.com mailto:marc.ge...@gmail.com het volgende: Hi all, I have a few tagging questions * How do I tag a 'Feestzaal/Sale de fête' that is part of a pub/restaurant ? usually it has a different name than the restaurant/pub http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcommunity_centre You could add an operator= tag to identify the place where to go for renting it, eg the pub/restaurant near by. Also website= may informative to the fact it is not a'government' building As a point in the restaurant building? Just as you would map individual shops in a shopping center. * How do I tag a place that rents rooms for conferences, and other activities ? e.g. http://www.roosendael.be I don't know that one, maybe with the proposed feature rental: http://wiki.openstreetmap.org/wiki/Proposed_features/rental ? http://wiki.openstreetmap.org/wiki/Proposed_features/Conference_Centre mvg Gerard regards m ___ Talk-be mailing list Talk-be@openstreetmap.org mailto:Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-legal-talk] Share-Alike requirements for other data sources?
Hola Jaime, Thanks so much for your email(s). I just love the internet and how it can connect people and build relationships with people around the world. You should read the actual licenses, but the spirit of the licenses, as I understand them (IANAL), is: Very easy to get lost in the labyrinth of links associated with the OSM license. Is the link below the license I should go by or is it somewhere else? http://www.openstreetmap.org/copyright Once again thank you for your time and your reply. Rob 2012/4/18 Rob smartt...@gmail.com: Greetings Salutations, Thank you in advance for taking the time read and respond to this message. After reading numerous webpages regarding the OSM license I am still unclear regarding Share-Alike implications. Please be aware that you are mixing the (by the way, non-official) interpretations of the CC-BY-SA and the ODBL. We are transitioning from one to the other right now. You should read the actual licenses, but the spirit of the licenses, as I understand them (IANAL), is: * Both require attribution * CC-BY-SA requires share-alike for the published, derivative work. Nothing is said about other rights, such as data or database. * ODBL requires share-alike for the database (by publishing modifications or method to obtain them), not for derivative works. All rights are covered. This is an oversimplification and not legal advice, again please read the licenses or consult a lawyer if in doubt. -- Jaime Crespo ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk On Apr 18, 2012, at 7:20 PM, Jaime Crespo wrote: * ODBL requires share-alike for the database (by publishing modifications or method to obtain them), not for derivative works. All rights are covered. Sorry, I meant produced works, not derivative works. -- Jaime Crespo ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Share-Alike requirements for other data sources?
El 19/04/2012 16:19, Rob smartt...@gmail.com escribió: You should read the actual licenses, but the spirit of the licenses, as I understand them (IANAL), is: Very easy to get lost in the labyrinth of links associated with the OSM license. Yep, you may be right, but if you want to know all the ins and outs, you have to read the small print. The license change can also be confusing. Is the link below the license I should go by or is it somewhere else? From there, you can reach: http://creativecommons.org/licenses/by-sa/2.0/legalcode That is the current license for the database. In a matter of days, this will be the new license: http://opendatacommons.org/licenses/odbl/1.0/ -- Jaime Crespo ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] New editors
On Wed, Apr 18, 2012 at 10:21 PM, Mike N nice...@att.net wrote: ... But one newbie deleted about 300 streets, seemingly for a wedding-related event map :-( ... I couldn't help laughing, that's actually pretty funny. Did you contact the user? Greetings, Floris Looijesteijn ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New editors
On 4/19/2012 3:50 AM, Floris Looijesteijn wrote: On Wed, Apr 18, 2012 at 10:21 PM, Mike Nnice...@att.net wrote: ... But one newbie deleted about 300 streets, seemingly for a wedding-related event map :-( ... I couldn't help laughing, that's actually pretty funny. Did you contact the user? Yes, I sent a message, but got no reply. Perhaps they were too embarrassed, so the revert will be initiated. It would be funny to get the printed wedding invitation, containing just the remaining major streets! ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New editors
On Thu, Apr 19, 2012 at 7:16 PM, Mike N nice...@att.net wrote: On 4/19/2012 3:50 AM, Floris Looijesteijn wrote: On Wed, Apr 18, 2012 at 10:21 PM, Mike Nnice...@att.net wrote: ... But one newbie deleted about 300 streets, seemingly for a wedding-related event map :-( ... I couldn't help laughing, that's actually pretty funny. Did you contact the user? Yes, I sent a message, but got no reply. Perhaps they were too embarrassed, so the revert will be initiated. It would be funny to get the printed wedding invitation, containing just the remaining major streets! This kind of wedding map edit actually happened to my country in 2010. :-) http://lists.openstreetmap.org/pipermail/talk-ph/2010-June/002314.html ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] handheld gps unit
hi, what are recommendations for a handheld reasonably priced gps unit? -- regards Kenneth Gonsalves ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] handheld gps unit
I'm very pleased with my Garmin eTrex Vista HCx.
Bob
if (*ra4 != 0xffc78948) { return false; }
On 19 Apr 2012, at 13:20, kenneth gonsalves wrote:
hi,
what are recommendations for a handheld reasonably priced gps unit?
--
regards
Kenneth Gonsalves
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] handheld gps unit
On Thu, 19 Apr 2012 21:20:10 kenneth gonsalves wrote: hi, what are recommendations for a handheld reasonably priced gps unit? Bit old these days, although maybe that makes it cheaper, but I love my Garmin Geko 201. Waterproof, takes two AAA cells. Reasonably accurate. Robust. Well-implemented features. I'd like to know what's current, but I am always extremely happy when I use my Geko. Best wishes, Andrew ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] handheld gps unit
Hi, Am 19.04.2012 14:20, schrieb kenneth gonsalves: what are recommendations for a handheld reasonably priced gps unit? I am also very happy with my Garmin eTrex Vista HCx, allthough it doesn't feature a recent GPS chipset. On the german list there is a discussion at the moment about current GPS-loggers (+ Bluetooth-connection to use them as GPS dongle for other devices) and their chipsets. Very interesting (and new) devices that have been mentioned there: http://www.kowoma.de/gps/geraetetests/wintec_wbt202/wbt202_p1.html (using u-blox 5) http://www.kowoma.de/gps/geraetetests/iblue%20747A+/iblue747A+.html (MTKII-chipset) The pages are in german but you can find other reviews of these devices via Google. Depends on what exactly you are looking for. A device with a big screen for map display and navigation or just a GPS-logger with pushbutton to create waypoints ... Best regards, Jannis ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New editors
But one newbie deleted about 300 streets, seemingly for a wedding-related event map :-( ... I couldn't help laughing, that's actually pretty funny. Did you contact the user? Yes, I sent a message, but got no reply. Perhaps they were too embarrassed, so the revert will be initiated. It would be funny to get the printed wedding invitation, containing just the remaining major streets! This kind of wedding map edit actually happened to my country in 2010. :-) http://lists.openstreetmap.org/pipermail/talk-ph/2010-June/002314.html I wonder what the intent of the user was? It appears to me that they were attempting to create a certain type of map by altering the data. Here on the list we would argue that the issue the user is tackling is a rendering issue, not a data issue. Is this a clue to a different way of rendering? In the same way that streetmap and cyclemap have the same data but produce different looking maps? Perhaps a renderer could make a weddingmap :-D It could work by having the user center the map on their one point of interest, and then the rendering process would have high detail around that center point, but have the detail drop off successively the greater the distance from the center point. So minor streets around the wedding venue would be rendered because that is useful for navigation and parking. But minor streets further away from the venue would not be rendered, because the intent is to highlight only the chosen point of interest and major transportation routes to that point. nick *** WARNING: This email (including any attachments) may contain legally privileged, confidential or private information and may be protected by copyright. You may only use it if you are the person(s) it was intended to be sent to and if you use it in an authorised way. No one is allowed to use, review, alter, transmit, disclose, distribute, print or copy this email without appropriate authority. If this email was not intended for you and was sent to you by mistake, please telephone or email me immediately, destroy any hardcopies of this email and delete it and any copies of it from your computer system. Any right which the sender may have under copyright law, and any legal privilege and confidentiality attached to this email is not waived or destroyed by that mistake. It is your responsibility to ensure that this email does not contain and is not affected by computer viruses, defects or interference by third parties or replication problems (including incompatibility with your computer system). Opinions contained in this email do not necessarily reflect the opinions of the Department of Transport and Main Roads, Maritime Safety Queensland or endorsed organisations utilising the same infrastructure. *** ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New editors
This seems to be a recurring thing. I have personally caught, contacted and reverted 3 people who just wanted a simplified map of an area. I just happened to spot their edits in LiveEditMapViewer. I haven't really been paying as much attention to it lately so I'm sure a number of such edits have slipped through. Somehow the users didn't understand that they were saving their changes to THE database and that it would affect everyone who uses OSM data. I'm not sure how to get the message across any better. Toby On Thu, Apr 19, 2012 at 5:21 PM, nicholas.g.lawre...@tmr.qld.gov.au wrote: But one newbie deleted about 300 streets, seemingly for a wedding-related event map :-( ... I couldn't help laughing, that's actually pretty funny. Did you contact the user? Yes, I sent a message, but got no reply. Perhaps they were too embarrassed, so the revert will be initiated. It would be funny to get the printed wedding invitation, containing just the remaining major streets! This kind of wedding map edit actually happened to my country in 2010. :-) http://lists.openstreetmap.org/pipermail/talk-ph/2010-June/002314.html I wonder what the intent of the user was? It appears to me that they were attempting to create a certain type of map by altering the data. Here on the list we would argue that the issue the user is tackling is a rendering issue, not a data issue. Is this a clue to a different way of rendering? In the same way that streetmap and cyclemap have the same data but produce different looking maps? Perhaps a renderer could make a weddingmap :-D It could work by having the user center the map on their one point of interest, and then the rendering process would have high detail around that center point, but have the detail drop off successively the greater the distance from the center point. So minor streets around the wedding venue would be rendered because that is useful for navigation and parking. But minor streets further away from the venue would not be rendered, because the intent is to highlight only the chosen point of interest and major transportation routes to that point. nick *** WARNING: This email (including any attachments) may contain legally privileged, confidential or private information and may be protected by copyright. You may only use it if you are the person(s) it was intended to be sent to and if you use it in an authorised way. No one is allowed to use, review, alter, transmit, disclose, distribute, print or copy this email without appropriate authority. If this email was not intended for you and was sent to you by mistake, please telephone or email me immediately, destroy any hardcopies of this email and delete it and any copies of it from your computer system. Any right which the sender may have under copyright law, and any legal privilege and confidentiality attached to this email is not waived or destroyed by that mistake. It is your responsibility to ensure that this email does not contain and is not affected by computer viruses, defects or interference by third parties or replication problems (including incompatibility with your computer system). Opinions contained in this email do not necessarily reflect the opinions of the Department of Transport and Main Roads, Maritime Safety Queensland or endorsed organisations utilising the same infrastructure. *** ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] handheld gps unit
kenneth gonsalves writes: hi, what are recommendations for a handheld reasonably priced gps unit? I still enjoy my Columbus/Visiontac V-900. It's a GPS data logger which records georeferenced audio notes. It's quite compact, and the battery lasts from morning to night (rechargable). -- --my blog is athttp://blog.russnelson.com Crynwr supports open source software 521 Pleasant Valley Rd. | +1 315-600-8815 Potsdam, NY 13676-3213 | Sheepdog ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] GPS mit *gutem* Empfang?
Jimmy_K Jimmy_K at gmx.at writes: Aktuelle ist der WBT-202 und dieser hat dank des u-blox5 zum MTKII des 747A+ aufholen können: http://www.kowoma.de/gps/geraetetests/wintec_wbt202/wbt202_p1.html Stimmt. Er ist aber, wenn ich den Test richtig verstehe, nicht deutlich besser. Außerdem (Zitat vom von dir verlinkten Test): | ... dass nur die drei NMEA-Datensätze RMC, GGA (teilweise) und VTG geloggt | und somit exportiert werden können. Tiefschürfende Informationen zu HDOP, | VDOP, Anzahl und Details der empfangenen Satelliten stehen nicht zur | Verfügung. Hier ist der iBlue747A+ flexibler einzusetzen. Das Problem hatte auch der WBT 201 bereits. Man muss dem, was der Logger aufgezeichnet hat, blind vertrauen, da im Nachgang kein Filtern der Daten mehr möglich ist. Ich lege mir mein Log dann halt auf die OSM-Daten und wo mein Log gravierend abweicht, lösche ich diese Bestandteile des GPX-Tracks raus. Mir wäre bei einem neuen Logger schon wichtig, dass ich nach dem Auslesen solche Punkte, die bei schlechten Empfangsverhältnissen geloggt wurden, aussortieren kann. Prinzipiell wäre ich auch an einem Garmin-Gerät interessiert, aber hier fällt mir die Auswahl schwer. Zudem gibt es wohl nur wenige Garmin-Geräte mit MTK II Chipsatz. Eine Angabe zum Chipsatz vermisse ich auf der Garmin-Webseite komplett. Aktuell brauche ich erstmal direkt Ersatz für den WBT 201 um künftig Tracks mit besserer Qualität loggen zu können. Kann jemand bestätigen, dass das Bluetooth beim iBlue747A+ tatsächlich nach einigen Minuten ohne Verbindung ausgeschaltet wird? Wie schon erwähnt wäre mir das schon wichtig, denn in den allermeisten Fällen werde ich kein Bluetooth brauchen und Akku-Laufzeit ist mir da dann doch wichtiger. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massenumbenennung Relationen von Multipolygon in Boundary
Am 19.04.12 00:59, schrieb Frederik Ramm: Hallo, On 04/19/2012 12:10 AM, Chris66 wrote: Ob die üblichen Regeln für Massenedits (Ankündigung auf der Liste etc.) eingehalten wurden, weiss ich nicht. Ich hab beim Autor nachgefragt. Denn wenn jetzt hier jeder einfach so die Grenzrelationen auf das aendern kann, was er gut findet, aender ich sie morgen weltweit auf multipolygon ;) wenn du dafür auf der englischen Liste eine Mehrheit findest... Thread Why boundaries should not be tagged as boundaries Die internationale Community wird vermutlich für den Widerstand eines kleinen badischen Dorfes gegen den Rest der Welt nur ein müdes Lächeln übrig haben. Angekündigt war es nicht, hat aber den *manuellen* Eintrag der Regionalschlüssel laut aktueller destatis-Liste als Ersatz der allgemeinen Gemeindeschluessel erheblich vereinfacht. Im Forum war der Aufschrei des Entsetzens eher verhalten: http://forum.openstreetmap.org/viewtopic.php?id=15135p=4 Es gab halt immer schon boundaries, und die Argumente für Multipolygon sind nun mal nicht sehr überzeugend. Bei boundary sind auch Knoten als admin_centre oder label erlaubt, sowie Unterrelationen zur Abbildung der Verwaltungshierarchie. Das ist beim multipolygon nicht erlaubt, weil es *nur* Geometrie sein soll. Würde man sich statt mit sinnloser Relizensierung mit einem vernünftigen Flächen-Datentyp befassen, hätte sich das Problem längst erledigt. Dann könnte eine boundary-Relation den Flächenumriss, den Verwaltungsmittelpunkt und die Unterelemente sauber zusammenfassen. Stattdessen ekelt man lieber altgediente OSM-Dogmatiker raus und wundert sich dann, wenn sich niemand mehr daran erinnert, warum man kein Multipolygon will. Gruß, ajoessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach Elbufer, Bad Schandau
On Thu, Apr 19, 2012 at 07:36:54AM +0200, Ronnie Soak wrote: Ich betrachte den Entwicklungsstand von Nominatim immer noch als beta. Nicht verwunderlich, bei der Komplexitaet der Aufgabe. Weiteres Beispiel gefaellig? Such nache Fischmarkt, Erfurt openstreetmap.org: Pedestrian Way Fischmarkt, Altstadt, Erfurt, Coburg, Free State of Thuringia, 99084, Federal Republic of Germany (land mass), Europehttp://www.openstreetmap.org/?minlon=11.0283880233765minlat=50.9776000976562maxlon=11.0291347503662maxlat=50.9780693054199 Richtiger Platz, aber Coburg ist eine Stadt (und ein Landkreis?) in Bayern und hat hier nichts zu suchen. Das liegt an einem alten OpenGeoDB-Node: http://www.openstreetmap.org/browse/node/240076850 Offenbar wurden die Kreise bei dem Import als place=region eingetragen, das sollte wohl eher place=county sein. In jedem Fall werden die place=region Nodes mit dem nächsten Nominatim- Update (nach dem Lizenzwechsel) gänzlich aus den Adressen verschwinden. Dann hat sich das Problem ohnehin gelöst. openstreetmap.de Fischmarkt, Altstadt, Erfurt, Ilm-Kreis, Free State of Thuringia, 99084, Federal Republic of Germany (land mass), Europehttp://openstreetmap.de/karte.html# Auch hier richtiger Platz, aber Erfurt ist eine kreisfreie Stadt, der Ilm-Kreis schliesst sich im Sueden an. Die Suche auf osm.de könnte man ruhig mal auf nominatim.osm.org umstellen. Die Mapquest-Instanz hat nach wie vor einen Datenstand von Dezember und soweit ich gehört habe, wird es auch für einige Zeit nach dem Lizenzwechsel keine Updates geben. (Was durchaus Sinn macht dort, denn der Lizenwechsel wird einiges an Boundary-Polygonen kaputt machen, sodass es anfänglich wohl ein bisschen chaotisch wird mit den Addressen, die Nominatim zurückgibt.) Gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach Elbufer, Bad Schandau
Am 19.04.12 08:37, schrieb Sarah Hoffmann: Offenbar wurden die Kreise bei dem Import als place=region eingetragen, das sollte wohl eher place=county sein. Die englische Wikipeida hat sich auf district als Übersetzung für den deutschen Kreis geeinigt: http://en.wikipedia.org/wiki/Districts_of_Germany http://en.wikipedia.org/wiki/Talk:Districts_of_Germany#country_vs_district Gruß, Andre Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massenumbenennung Relationen von Multipolygon in Boundary
Moin, Am 19.04.2012 00:59, schrieb Frederik Ramm: Hallo, On 04/19/2012 12:10 AM, Chris66 wrote: Ob die üblichen Regeln für Massenedits (Ankündigung auf der Liste etc.) eingehalten wurden, weiss ich nicht. Ich hab beim Autor nachgefragt. Denn wenn jetzt hier jeder einfach so die Grenzrelationen auf das aendern kann, was er gut findet, aender ich sie morgen weltweit auf multipolygon ;) ist vielleicht gar keine so schlechte Idee. ;-) Dann wird das 'Problem' vielleicht mal international offensichtlich. Im Moment sieht es ja eher so aus, als wenn das 'Problem boundary' außerhalb einiger gallischer Dörfer international nicht so recht existiert ... Andererseits wäre es natürlich auch kein Problem, innerhalb einer type=multipolygon boundary=administrative die Rolle admin_centre=* zu behandeln ... Genauso, wie es (sogar unabhängig von der Auswertung einer Relation) möglich wäre admin_centre=ADMIN_LEVEL als Tag am Ort des Geschehens auszuwerten. Der Bezug zur Relation ist über die geografischen DB-Funktionen gegeben. Bei der letzten Variante - bräuchte man weder einen speziellen Relationstyp - noch bräuchte man eine Rollen-Sonderbehandlung bei multipolygon - könnten Renderer die Funktion des Ortes unabhängig von jeglicher Relation kennzeichnen - wäre eine Sonderbehandlung bei der Auswertung nur erforderlich, wenn man tatsächlich einen echten Bezug zwischen admin_centre und der boundary benötigt Nur der Aufwand bei einer Änderung ist geringfügig höher und geringfügig fehleranfälliger - ist aber in meinen Augen durchaus handhabbar. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach Elbufer, Bad Schandau
On Thu, Apr 19, 2012 at 08:51:34AM +0200, Andre Joost wrote: Am 19.04.12 08:37, schrieb Sarah Hoffmann: Offenbar wurden die Kreise bei dem Import als place=region eingetragen, das sollte wohl eher place=county sein. Die englische Wikipeida hat sich auf district als Übersetzung für den deutschen Kreis geeinigt: http://en.wikipedia.org/wiki/Districts_of_Germany http://en.wikipedia.org/wiki/Talk:Districts_of_Germany#country_vs_district Was jetzt aber nicht relevant ist für OSM. Es gibt so etwas ähnliches wie einen Konsens in OSM, dass die Grenzen, die mit admin_level=6 getaggt sind, place=county entsprechen. place=district ist in OSM ein Stadtteil. Gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massenumbenennung Relationen von Multipolygon in Boundary
Moin, Am 19.04.2012 07:59, schrieb Andre Joost: Es gab halt immer schon boundaries, und die Argumente für Multipolygon sind nun mal nicht sehr überzeugend. Bei boundary sind auch Knoten als admin_centre oder label erlaubt, sowie Unterrelationen zur Abbildung der Verwaltungshierarchie. Das ist beim multipolygon nicht erlaubt, weil es *nur* Geometrie sein soll. Aber sind die Argumente für boundary denn tatsächlich überzeugender? label sehe ich bei multipolygon genauso als sinnvoll an, es sollte also auch dort behandelt werden (können). admin_centre siehe meine Antwort von 09:13 auf Frederiks Beitrag. Unterrelationen: Ich sehe durchaus einen Sinn in Unterrelationen, allein aufgrund der Größe und Handhabbarkeit, sprich also die 'französische Teilung' und das bleibt dann nur Geometrie. Aber ist es wirklich notwendig und sinnvoll, die Verwaltungsstruktur innerhalb einer Relation abzubilden? Wenn man das tut, setzt man (als Beispiel mal SH) das Kreis_gebiet_ aus den Amts_gebieten_ zusammen. Dabei geht dann m. E. aber die Kreis_grenze_ verloren bzw. ist nicht mehr eindeutig, die muss man also als _Grenz_relation zusätzlich erfassen. Was hat man dann außer der Zusammenfassung der Amtsgebiete, die aber über den geografischen Zusammenhang der Amtsgebiete innerhalb des _Kreisgebietes_der_Grenzrelation_ gegeben ist, gewonnen? Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massenumbenennung Relationen von Multipolygon in Boundary
Am 19.04.12 09:46, schrieb Georg Feddern: Aber ist es wirklich notwendig und sinnvoll, die Verwaltungsstruktur innerhalb einer Relation abzubilden? Wenn man das tut, setzt man (als Beispiel mal SH) das Kreis_gebiet_ aus den Amts_gebieten_ zusammen. Nein, es soll nur auf die Relationen der Ämter verwiesen werden. Die Kreisgrenze bleibt als Fläche/Polygon daneben definiert. So kann man auf einfache Weise z.B. Verbandsgemeinde Bad Kreuznach und Verbandsgemeindefreie Stadt Bad Kreuznach im Kreis Bad Kreuznach auseinanderhalten. Ohne sich die Grenzen jeweils anschauen zu müssen. Dabei geht dann m. E. aber die Kreis_grenze_ verloren bzw. ist nicht mehr eindeutig, die muss man also als _Grenz_relation zusätzlich erfassen. Als Polygon, ja. Was hat man dann außer der Zusammenfassung der Amtsgebiete, die aber über den geografischen Zusammenhang der Amtsgebiete innerhalb des _Kreisgebietes_der_Grenzrelation_ gegeben ist, gewonnen? Der simple Mapper kann nicht eben mal eine Postgis-Abfrage starten. Mit Relationen kommt er eher klar. Aber diese Art von Grenzrelationshierarchie ist eben ein kann, kein muß. Die Grenzlinienelemente sind nur in der/den Geometrie-Relation(en) bzw in neu zu schaffenden Flächenelementen drin. Gruß, Andre Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Burgen, Schlösser usw ... ;-)
Hi! Manfred A. Reiter wrote a) ein Rendering nutzen, das diese Sachen rendert (z.B. NOPs Wanderreitkarte) das bedeutet also warten, bis die Dinge dort erscheinen? Diese Karte wird momentan nicht aktualisiert, soll erst weitergehen wenn der Lizenzwechsel durch ist. Manfred A. Reiter wrote Manfred A. Reiter lt;ma.reiter@gt; wrote: Ich habe auch in eben diesem Thread gelesen, dass Schlösser und Burgen in Mapnik nicht gerendert werden ... IST das so? Kann ich was tun, um diese für Touris evtl wichtige Info trotzdem sichtbar zu machen? Ist das so??? Meine Rückfrage kommt deshalb, weil ich hier http://www.openstreetmap.de/karte.html?zoom=15lat=45.81389lon=14.12989layers=B000TT zwar einen Höhleneingang finde, aber die Burg nicht erscheint. Das kann zwei Ursachen haben: 1. Burgen werden im Kartenstil nicht berücksichtigt. Ich bilde mir aber ein, in einem anderen Thread gelesen zu haben, daß Sven das im deutschen Stil eingebaut hat. 2. Objekte liegen zu nahe beieinander. Mapnik zeichnet dann das erste Objekt oder den ersten Text und läßt alle weiteren Objekte an der Stelle, die drübergeschmiert würden, einfach weg. Dabei ist es mehr oder weniger Zufall, welches Objekt zuerst kommt. Es kann also durchaus sein, daß der Höhleneingang angezeigt wird, und deshalb Brücke und Burg weggelassen werden. Hier in der Gegend ärgern sich z.B. schon lange die Nürnberger darüber, daß auf der OSM Karte die viel kleinere Nachbarstadt Fürth angezeigt und Nürnberg weggelassen wird. Fürth kommt im Alphabet halt vorher. :-) bye Nop -- View this message in context: http://gis.19327.n5.nabble.com/Burgen-Schlosser-usw-tp5641957p5651240.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massenumbenennung Relationen von Multipolygon in Boundary
Hallo, On 04/19/12 07:59, Andre Joost wrote: Angekündigt war es nicht, hat aber den *manuellen* Eintrag der Regionalschlüssel laut aktueller destatis-Liste als Ersatz der allgemeinen Gemeindeschluessel erheblich vereinfacht. Solche Aenderungen sind nicht nur vorher anzukuendigen, sondern auch vorher zu diskutieren. Was will ich aendern, wie will ich dabei vorgehen, hat jemand was dagegen. Es gab halt immer schon boundaries, und die Argumente für Multipolygon sind nun mal nicht sehr überzeugend. So etwas ist vorher zu diskutieren und nicht hinterher. 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] Burgen, Schlösser usw ... ;-)
Hallo, Am 19. April 2012 10:48 schrieb NopMap ekkeh...@gmx.de: Manfred A. Reiter wrote Meine Rückfrage kommt deshalb, weil ich hier http://www.openstreetmap.de/karte.html?zoom=15lat=45.81389lon=14.12989layers=B000TT zwar einen Höhleneingang finde, aber die Burg nicht erscheint. Das kann zwei Ursachen haben: 1. Burgen werden im Kartenstil nicht berücksichtigt. Ich bilde mir aber ein, in einem anderen Thread gelesen zu haben, daß Sven das im deutschen Stil eingebaut hat. Stimmt, inzwischen ist die gesuchte Burg auch da, wenn man weiter reinzoomt: http://www.openstreetmap.de/karte.html?zoom=18lat=45.81561lon=14.12701layers=B000TT Grüße, Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massenumbenennung Relationen von Multipolygon in Boundary
Am 19.04.2012 10:07, schrieb Andre Joost: Nein, es soll nur auf die Relationen der Ämter verwiesen werden. Die Kreisgrenze bleibt als Fläche/Polygon daneben definiert. So kann man auf einfache Weise z.B. Verbandsgemeinde Bad Kreuznach und Verbandsgemeindefreie Stadt Bad Kreuznach im Kreis Bad Kreuznach auseinanderhalten. Ohne sich die Grenzen jeweils anschauen zu müssen. OK, das ist eine Möglichkeit ... Ich nutze dafür allerdings den name:prefix (resp. bei Bedarf den name:suffix). Ist genauso menschenlesbar - und kann zusätzlich programmtechnisch (z.B. vom Renderer) verwendet werden, falls gewünscht. Der simple Mapper kann nicht eben mal eine Postgis-Abfrage starten. Mit Relationen kommt er eher klar. Aber diese Art von Grenzrelationshierarchie ist eben ein kann, kein muß. Die Grenzlinienelemente sind nur in der/den Geometrie-Relation(en) bzw in neu zu schaffenden Flächenelementen drin. Das Argument kann ich als Gemeinde- bis Bundesland-Extrakt-Verwender zwar durchaus nachvollziehen. Trotzdem sehe ich da mit osmconvert und osmfilter auch Kleinanwender-Möglichkeiten gegeben. Und letztendlich bleibt es damit trotzdem nur eine Sammel-Relation - mit deren Vorzügen, aber eben auch mit deren Nachteilen. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] http://wiki.openstreetmap.org/wiki/DE:BBBike_@_World
hi martin, es geht bestimmt um bbbike.org und nicht um bbbike.de - kleiner aber feiner unterschied. Gruss walter -- View this message in context: http://gis.19327.n5.nabble.com/http-wiki-openstreetmap-org-wiki-DE-BBBike-World-tp5650066p5651293.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach Elbufer, Bad Schandau
Am 19. April 2012 09:18 schrieb Sarah Hoffmann lon...@denofr.de: On Thu, Apr 19, 2012 at 08:51:34AM +0200, Andre Joost wrote: Am 19.04.12 08:37, schrieb Sarah Hoffmann: Offenbar wurden die Kreise bei dem Import als place=region eingetragen, das sollte wohl eher place=county sein. m.E. braucht man für diese klar definierten Verwaltungseinheiten überhaupt kein place, das ist mit admin_level und boundary=administrative hinreichend definiert. place=district ist in OSM ein Stadtteil. das höre ich zum ersten Mal, bisher war ich von place=suburb ausgegangen, ggf. noch unterteilt in place=quarter und neighbourhood. Gem. taginfo kommt place=district überhaupt nicht in den Daten vor, es findet sich zwar ein place=city_district, aber gerade mal an 38 Stellen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach Elbufer, Bad Schandau
Am 19.04.12 11:33, schrieb Martin Koppenhoefer: Am 19. April 2012 09:18 schrieb Sarah Hoffmannlon...@denofr.de: On Thu, Apr 19, 2012 at 08:51:34AM +0200, Andre Joost wrote: Am 19.04.12 08:37, schrieb Sarah Hoffmann: Offenbar wurden die Kreise bei dem Import als place=region eingetragen, das sollte wohl eher place=county sein. m.E. braucht man für diese klar definierten Verwaltungseinheiten überhaupt kein place, das ist mit admin_level und boundary=administrative hinreichend definiert. Nö, Kreis und kreisfreie Stadt stehen auf gleichem admin_level. Ebenso Verbandsgemeinde und amtsfreie Orte auf 7, sowie Gemeinden und Städte auf level 8. name:prefix ist auch suboptimal, da sich manche Städte eben gerne als Hansestadt/Freie und Hansestadt/Kolpingstadt/Rattenfängerstadt/wass-weiss-ich-Stadt bezeichnen: http://www.mik.nrw.de/themen-aufgaben/kommunales/erfolgsmodell-kommunale-selbstverwaltung/strukturen/bezeichnungen/genehmigte-bezeichnungen.html Und ein *stadt* oder *amt* im Namen ist auch kein eindeutiges Indiz für Stadtrechte bzw Amtseigenschaften :-( Um das mal aufzudröseln, habe ich für level 6 und 8 hier entsprechende tags eingeführt: http://wiki.openstreetmap.org/wiki/DE:Grenze_zeichnen#Politische_Grenze http://wiki.openstreetmap.org/wiki/DE:Gemeindegrenze#Relation_anlegen place=* fällt da leider aus, weil das im Zusammenhang mit type=multipolygon von mkgmap und josm als Siedlungsfläche mißverstanden wird. Deshalb de:place mit city/county/town/village als mögliche Werte. Für level 7 sind mir keine passenden englischen Begriffe eingefallen. Gruß, Andre Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach Elbufer, Bad Schandau
On 19.04.12 11:33, Martin Koppenhoefer wrote: [place=region] m.E. braucht man für diese klar definierten Verwaltungseinheiten überhaupt kein place, das ist mit admin_level und boundary=administrative hinreichend definiert. ACK. IMO sollte man dem Nominatim beibringen, dass es Staaten gibt, deren admin-boundaries mittlerweile halbwegs vollständig sind und daher diese gedachten Wolken um Place Nodes herum entbehrlich und kontraproduktiv sind! In AT gibt's dasselbe Theater, grade die Wolken um place=region scheinen mir zu groß gedacht und -- da es die Grenzhierarchie längst gibt - entbehlich. place=district ist in OSM ein Stadtteil. das höre ich zum ersten Mal, bisher war ich von place=suburb ausgegangen, ggf. noch unterteilt in place=quarter und neighbourhood. Gem. taginfo kommt place=district überhaupt nicht in den Daten vor, es findet sich zwar ein place=city_district, aber gerade mal an 38 Stellen. ACK. Das sollte man mal final spezifizieren (und auch in Mapnik+Nominatim umsetzen). In Wien (und das gilt so ähnlich auch in anderen größeren österr. Städten) gibt es a) (Stadt-/Gemeinde-)Bezirke (admin_level 9) b) Katastralgemeinden (hauptsächlich durch Place Nodes abgebildet; Grenzen zu erfassen wäre aber denkbar) c) Grätzelnamen (entspr. place=neighbourhood) Grade bei a) und b) (momentan beide als place=suburb gemappt, was äußerst unbefriedigend ist) wäre eine durchgängige Größen- und Ebenenunterscheidung wünschenswert, in der Beschriftung im Mapnik/Standardstil genauso wie im Nominatim (der sollte überhaupt nur a) berücksichtigen und b) und c) in seiner Hierarchie ignorieren...). /al ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massenumbenennung Relationen von Multipolygon in Boundary
Am 19. April 2012 10:58 schrieb Frederik Ramm frede...@remote.org: On 04/19/12 07:59, Andre Joost wrote: Angekündigt war es nicht, hat aber den *manuellen* Eintrag der Regionalschlüssel laut aktueller destatis-Liste als Ersatz der allgemeinen Gemeindeschluessel erheblich vereinfacht. Solche Aenderungen sind nicht nur vorher anzukuendigen, sondern auch vorher zu diskutieren. Was will ich aendern, wie will ich dabei vorgehen, hat jemand was dagegen. +1 automatische Edits müssen vorher diskutiert werden, es ist ein Unding, dass nach wie vor manche Mapper sich das Recht rausnehmen, flächendeckend Ihre Meinung durchzusetzen bei Themen, die in der Community umstritten sind (genauso leidig sind Massenimporte, die vorher nicht angekündigt und diskutiert wurden). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Jahr der Errichtung - Ergänzung des Lübeck-Wiki
Hi ! habe gerade folgendes ergänzt: Jahr der Errichtung Was heute gebaut wird, das wissen wir. Aber was ist in x-Jahren. Wenn wir gerade schon dabei sind Hausnummern zu erfassen und auch neu errichtete Gebäude sehen, dann sollten wir noch ein Zusatztag build_year=* setzen. Bei alten Gebäuden finden sich hierzu oftmals Tafeln an den Gebäuden. Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Jahr der Errichtung - Ergänzung des Lübeck-Wiki
Am 19.04.12 12:16, schrieb Jan Tappenbeck: Hi ! habe gerade folgendes ergänzt: Jahr der Errichtung Was heute gebaut wird, das wissen wir. Aber was ist in x-Jahren. Wenn wir gerade schon dabei sind Hausnummern zu erfassen und auch neu errichtete Gebäude sehen, dann sollten wir noch ein Zusatztag build_year=* setzen. Bei alten Gebäuden finden sich hierzu oftmals Tafeln an den Gebäuden. Da gibts doch schon was: http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Building_attributes#Date_of_construction http://taginfo.openstreetmap.org/keys/?key=construction_year http://taginfo.openstreetmap.org/keys/?key=year_of_construction Gruß, Andre Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Jahr der Errichtung - Ergänzung des Lübeck-Wiki
Am 19. April 2012 12:16 schrieb Jan Tappenbeck o...@tappenbeck.net: Hi ! habe gerade folgendes ergänzt: Jahr der Errichtung Was heute gebaut wird, das wissen wir. Aber was ist in x-Jahren. Wenn wir gerade schon dabei sind Hausnummern zu erfassen und auch neu errichtete Gebäude sehen, dann sollten wir noch ein Zusatztag build_year=* setzen. Bei alten Gebäuden finden sich hierzu oftmals Tafeln an den Gebäuden. Ich dachte, wir nutzen englische Wörter als Tags (SCNR) warum willst Du da auf Biegen und Brechen was durchsetzen, was bereits universell verwendbar anders eingeführt ist? start_date ist der tag, der allgemein dafür verwendet wird (wenn er in Verbindung mit dem Key building gesetzt ist), und der auch für alles mögliche andere verwendet werden kann. Wenn es um voraussichtliche Baufertigstellung geht, habe ich noch dieses gefunden: http://wiki.openstreetmap.org/wiki/Key:opening_date build_year gibt es erst 21 mal, das sollte man im Wiki nicht als etablierte Empfehlung eintragen, maximal als proposal. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massenumbenennung Relationen von Multipolygon in Boundary
On 19/04/12 07:59, Andre Joost wrote: Am 19.04.12 00:59, schrieb Frederik Ramm: Hallo, On 04/19/2012 12:10 AM, Chris66 wrote: Ob die üblichen Regeln für Massenedits (Ankündigung auf der Liste etc.) eingehalten wurden, weiss ich nicht. Ich hab beim Autor nachgefragt. Denn wenn jetzt hier jeder einfach so die Grenzrelationen auf das aendern kann, was er gut findet, aender ich sie morgen weltweit auf multipolygon ;) Es geht nicht um weltweite Edits sondern um regionale. Was willst Du machen, wenn ich die 20 Kreise meiner Umgebung anpasse und sie dann auch noch zu den angrenzenden Kreisen in Frankreich passen ? Warum sind denn die Grenzmauern weltweit so in vielen Köpfen zementiert ? wenn du dafür auf der englischen Liste eine Mehrheit findest... Thread Why boundaries should not be tagged as boundaries +1 Die internationale Community wird vermutlich für den Widerstand eines kleinen badischen Dorfes gegen den Rest der Welt nur ein müdes Lächeln übrig haben. Es gibt auch noch badischer Dörfer etwas weiter südlich, in denen man sich mehr mit seine gallischen Nachbar verbunden fühlt. Ich würde auch vor Jahren mal angepammt, da ich beim Eintragen der PLZ-Relationen die Multipolygone durch boundary ersetzt habe. Habe es damals zurückgesetzt, war aber nie überzeugt. Es gab halt immer schon boundaries, und die Argumente für Multipolygon sind nun mal nicht sehr überzeugend. Bei boundary sind auch Knoten als admin_centre oder label erlaubt, sowie Unterrelationen zur Abbildung der Verwaltungshierarchie. Das ist beim multipolygon nicht erlaubt, weil es *nur* Geometrie sein soll. Ein Vorteil der boundaries, wobei label bei multipolygonen oft wohl auch angebracht ist. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massenumbenennung Relationen von Multipolygon in Boundary
On Wed, Apr 18, 2012 at 11:41:02PM +0200, Tirkon wrote: Moin, offensichtlich hat jemand hier und möglicherweise in weiteren Changesets massenweise den Typ von Grenz-Relationen von multipolygon auf boundary geändert: http://www.openstreetmap.org/browse/changeset/10934495 Der OSM Inspektor gibt jetzt eine Warnung aus: Ist diese Änderung von multipolygon auf boundary nun korrekt oder nicht? Das ist ein Alter Hut - Als ich die dinger in NRW vor Jahren alle eingetragen habe habe ich mit boundary angefangen. Ich halte das aber mittlerweile fuer Bullshit und habe mich von Frederik überzeugen lassen und habe das allermeiste auch auf multipolgon geaendert und damit weitergemacht. Ich habe die aenderung auch gesehen aber soll doch jeder den Datenbestand so kaputt machen dürfen wie er will :) Dinge die gleich funktionieren sollten auch gleich heissen. Und das Thema inner/outer bildet genau das ab was die boundarys auch probieren. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Jahr der Errichtung - Ergänzung des Lübeck-Wiki
Hallo, Am Donnerstag, 19. April 2012 12:47:01 schrieb Martin Koppenhoefer: warum willst Du da auf Biegen und Brechen was durchsetzen, was bereits universell verwendbar anders eingeführt ist? start_date ist der tag, der allgemein dafür verwendet wird (wenn er in Verbindung mit dem Key building gesetzt ist), und der auch für alles mögliche andere verwendet werden kann. -1 start_date ist zu allgemein und kann sich auch auf den Laden im Haus oder sonst was beziehen. year_of_construction oder date_of_construction sind da schon eindeutiger. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Burgen, Schlösser usw ... ;-)
Am 19. April 2012 10:48 schrieb NopMap ekkeh...@gmx.de: Hi! Manfred A. Reiter wrote a) ein Rendering nutzen, das diese Sachen rendert (z.B. NOPs Wanderreitkarte) das bedeutet also warten, bis die Dinge dort erscheinen? Diese Karte wird momentan nicht aktualisiert, soll erst weitergehen wenn der Lizenzwechsel durch ist. Manfred A. Reiter wrote Manfred A. Reiter lt;ma.reiter@gt; wrote: Ich habe auch in eben diesem Thread gelesen, dass Schlösser und Burgen in Mapnik nicht gerendert werden ... IST das so? Kann ich was tun, um diese für Touris evtl wichtige Info trotzdem sichtbar zu machen? Ist das so??? Meine Rückfrage kommt deshalb, weil ich hier http://www.openstreetmap.de/karte.html?zoom=15lat=45.81389lon=14.12989layers=B000TT zwar einen Höhleneingang finde, aber die Burg nicht erscheint. Das kann zwei Ursachen haben: 1. Burgen werden im Kartenstil nicht berücksichtigt. Ich bilde mir aber ein, in einem anderen Thread gelesen zu haben, daß Sven das im deutschen Stil eingebaut hat. richtig, aber *nach* dieser Email ;-) 2. Objekte liegen zu nahe beieinander. Mapnik zeichnet dann das erste Objekt oder den ersten Text und läßt alle weiteren Objekte an der Stelle, die drübergeschmiert würden, einfach weg. Dabei ist es mehr oder weniger Zufall, welches Objekt zuerst kommt. Es kann also durchaus sein, daß der Höhleneingang angezeigt wird, und deshalb Brücke und Burg weggelassen werden. Hier in der Gegend ärgern sich z.B. schon lange die Nürnberger darüber, daß auf der OSM Karte die viel kleinere Nachbarstadt Fürth angezeigt und Nürnberg weggelassen wird. Fürth kommt im Alphabet halt vorher. :-) bye Nop Sven hat das Problem für die OSM.de gelöst. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenbegleitende Radwege
On 18/04/12 14:41, Masi Master wrote: Am 17.04.2012, 22:49 Uhr, schrieb Chris66 chris66...@gmx.de: Am 17.04.2012 22:22, schrieb Bernhard Weiskopf: Straßenbegleitende Radwege mit den entsprechenden Schildern müssen von Radfahrern benutzt werden, hier setze ich zusätzlich an die Straße bicycle = no. Naja, das gilt aber nicht für alle Radfahrer. Ein Anhänger z.B. entbindet von der Benutzungspflicht des Radweges. Auch dar ich mich zum Linksabbiegen schon rechtzeitig auf die Straße orientieren, was bei fehlenden abgesenkten Bordsteinen schon einige 100m vorher sein kann. bicyle=no setze ich deshalb nur bei bei explizitem Verbot durch Zeichen 254 o.Ä. Auch wenn der Radweg unzumutbar ist, darf auf der Straße gefahren werden. Somit ist bicycle=no falsch (außer bei Verbotsschildern). +1 Lösche bitte die bicycle=no, wenn kein explizites Verbotsschild vorhanden ist. Es gibt aber auch Straßen mit abgesetzt parallel verlaufendem asphaltiertem Wirtschaftsweg oder Fußweg mit Fahrradfreigabe hier ergänzt man bicycle=yes (oder Tempo-30-Zonen, in denen keine nutzungspflichtigen Radwege erlaubt sind). Der abgesetzte Weg ist dann nicht als Radweg markiert, es besteht keine Nutzungspflicht und die für Radfahrer gefährlichere Straße darf benutzt werden (wird sie auch, z. B. von Rennradfahrern). Die Straße ist übrigens erheblich sicherer als die allermeisten Radwege. Man darf nur nicht äußerst rechts fahren, um die Autofahrer nicht zum Überholen ohne Abstand zu animieren. Aber das ist ein anderes Thema. +1 Bei diesem Thema hatte ich schon öfters Streit mit meine Freundin, da ich der Ansicht bin, daß Autos zum Überholen doch bitte eine eigene Spur benutzen sollen. Das sollte eigentlich Sache der Router sind. Ich würde mir eine Software wünschen, bei der mal bei allen Wegtypen (auch in Kombination von surface/smoothness usw.) die Priorisierung festlegen kann. +1 Mit einem vollgepackten Anhänger brauche ich Strecken mit möglichst geringster Steigung und glatten Fahrbahnbelag. Da nehme ich schon eher ein paar Kilometer Umweg in Kauf. Grüße fly P.S.: Die maximal erlaubte Länge eines Fahrradanhänger ist 25m. Bin leider noch nicht dazu gekommen eine zu schweissen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massenumbenennung Relationen von Multipolygon in Boundary
Hallo, On 04/19/12 13:10, fly wrote: Es geht nicht um weltweite Edits sondern um regionale. Im konkreten Fall sind 418 Kreis- und 746 Stadtgrenzen betroffen. Ist das noch ein regionaler Edit? 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] Jahr der Errichtung - Ergänzung des Lübeck-Wiki
Am 19. April 2012 13:18 schrieb Wolfgang wolfg...@ivkasogis.de: Hallo, Am Donnerstag, 19. April 2012 12:47:01 schrieb Martin Koppenhoefer: warum willst Du da auf Biegen und Brechen was durchsetzen, was bereits universell verwendbar anders eingeführt ist? start_date ist der tag, der allgemein dafür verwendet wird (wenn er in Verbindung mit dem Key building gesetzt ist), und der auch für alles mögliche andere verwendet werden kann. -1 start_date ist zu allgemein und kann sich auch auf den Laden im Haus oder sonst was beziehen. -1 der Laden im Haus ist sowieso ein anderes Objekt als das Haus. Um das sauber abzubilden sollte man dafür nicht daselbe Objekt verwenden. Das gibt an allen Stellen nur Probleme, z.B. beim Namen, bei der Stockwerksanzahl, beim operator und überall sonst, wo nicht komplett klar ist, worauf sich der tag bezieht. Das kann man auf verschiedene Arten tun, z.B. indem der Laden als Node gemappt wird, oder indem man für das Gebäude einen way macht, der als outer in einem Laden- Multipolygon member ist (oder anders rum, wenn die Fläche jeweils genau gleich ist). Ich halte es für besser, solche Trennungen auch durch getrennte Objekte darzustellen, als die tags immer weniger universell einsetzbar zu machen, indem man ständig neue Verschachtelungen erfindet, die kaum jemand auswerten kann. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massenumbenennung Relationen von Multipolygon in Boundary
Frederik Ramm wrote Im konkreten Fall sind 418 Kreis- und 746 Stadtgrenzen betroffen. Ist das noch ein regionaler Edit? ich finde schon, wenn man die Größe des gallischen Dorfes in Bezug zur Erde setzt, ist das sehr regional ;) Mit der Art und Weise dieser Aktion bin ich auch nicht so ganz happy aber das Ergebnis überzeugt mich voll. Gruss walter -- View this message in context: http://gis.19327.n5.nabble.com/Massenumbenennung-Relationen-von-Multipolygon-in-Boundary-tp5650288p5651590.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenbegleitende Radwege
Am 19. April 2012 13:46 schrieb fly lowfligh...@googlemail.com: P.S.: Die maximal erlaubte Länge eines Fahrradanhänger ist 25m. Bin leider noch nicht dazu gekommen eine zu schweissen. Cool, endlich mal wieder eine interessante Information auf talk-de ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Großbaustelle
On 18/04/12 14:55, Philippe Rieffel wrote: http://wiki.openstreetmap.org/**wiki/Tag:landuse%3Dbrownfieldhttp://wiki.openstreetmap.org/wiki/Tag:landuse%3Dbrownfield genau richtig. Was mache ich aber wenn Schrebergärten abgerissen wurden und nun eine Wiese vorhanden ist, welche noch dazu an einen Park angrenzt. Gebaut wird aber frühesten in einem Jahr. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Großbaustelle
Am 19. April 2012 14:31 schrieb fly lowfligh...@googlemail.com: On 18/04/12 14:55, Philippe Rieffel wrote: http://wiki.openstreetmap.org/**wiki/Tag:landuse%3Dbrownfieldhttp://wiki.openstreetmap.org/wiki/Tag:landuse%3Dbrownfield genau richtig. Was mache ich aber wenn Schrebergärten abgerissen wurden und nun eine Wiese vorhanden ist, welche noch dazu an einen Park angrenzt. Gebaut wird aber frühesten in einem Jahr. Das kommt drauf an, wie du die Aktualisierung einschätzt. Wenn Du sagst in den nächsten zwei Jahren komme ich nicht dazu zu überprüfen ob da jetzt ein Haus steht, andererseits keine andere Nutzung in betracht kommt, so halte ich brownfield für durchaus vertretbar. Das Contiloch[1] in Chemnitz existiert seit fast 20 Jahren und ich würde sagen, dass es ein brownfield ist, auch wenn sich mittlerweile seltene Arten ansiedeln, die jedem Naturschützer Freundentränen in die Augen treiben. Eine Wiederbebauung kommt nach wie vor in Betracht, falls nicht jemand die kleine Hufeisennase oder eine andere bedrohte Spezies entdeckt. Gruß, Falk [1] http://www.openstreetmap.org/?lat=50.834702lon=12.928843zoom=18layers=M ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Burgen, Schlösser usw ... ;-)
Manfred A. Reiter ma.rei...@gmail.com wrote: Ein solches Ticket gibt es: https://trac.openstreetmap.org/ticket/2247 Alter 3 Jahre ... Gibt es sowas wie ein Voting für das Ticket? ... oder wie kann ich die Macher des Mapnikstils von meinem Ansinnen überzeugen? Das Problem ist wohl, dass es in der datenbank die Spalte ruins nicht gibt. Meine Datenbank hat ein hstore. Deshalb kann ich das vergleichsweise einfach einbauen. Gruss Sven -- .. this message has been created using an outdated OS (UNIX-like) with an outdated mail- or newsreader (text-only) :-P /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Großbaustelle
On 19/04/12 14:47, Falk Zscheile wrote: Am 19. April 2012 14:31 schrieb fly lowfligh...@googlemail.com: On 18/04/12 14:55, Philippe Rieffel wrote: http://wiki.openstreetmap.org/**wiki/Tag:landuse%3Dbrownfieldhttp://wiki.openstreetmap.org/wiki/Tag:landuse%3Dbrownfield genau richtig. Was mache ich aber wenn Schrebergärten abgerissen wurden und nun eine Wiese vorhanden ist, welche noch dazu an einen Park angrenzt. Gebaut wird aber frühesten in einem Jahr. Das kommt drauf an, wie du die Aktualisierung einschätzt. Wenn Du sagst in den nächsten zwei Jahren komme ich nicht dazu zu überprüfen ob da jetzt ein Haus steht, andererseits keine andere Nutzung in betracht kommt, so halte ich brownfield für durchaus vertretbar. Das Contiloch[1] in Chemnitz existiert seit fast 20 Jahren und ich würde sagen, dass es ein brownfield ist, auch wenn sich mittlerweile seltene Arten ansiedeln, die jedem Naturschützer Freundentränen in die Augen treiben. Eine Wiederbebauung kommt nach wie vor in Betracht, falls nicht jemand die kleine Hufeisennase oder eine andere bedrohte Spezies entdeckt. Ich finde auch noch die ein oder andere Kohl-Sorte, auch ist am Pflanzenwuchs noch gut zu erkennen, wo Beete bzw Häuschen waren. Die Wiese wird jedoch eher schon als Park benutzt und ist öffentlich zugängig. Mal wieder ein Fall für landcover=* ? Bis bald fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach Elbufer, Bad Schandau
Sarah Hoffmann lon...@denofr.de wrote: Die Suche auf osm.de könnte man ruhig mal auf nominatim.osm.org umstellen. Da das außer mir sowieso wieder niemand machen wird... done. Sven -- Der normale Bürger ist nicht an der TU Dresden und schreibt auch nicht mit mutt. (Ulli Kuhnle in de.comp.os.unix.discussion) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Großbaustelle
Am 19. April 2012 15:21 schrieb fly lowfligh...@googlemail.com: On 19/04/12 14:47, Falk Zscheile wrote: Am 19. April 2012 14:31 schrieb fly lowfligh...@googlemail.com: On 18/04/12 14:55, Philippe Rieffel wrote: http://wiki.openstreetmap.org/**wiki/Tag:landuse%3Dbrownfieldhttp://wiki.openstreetmap.org/wiki/Tag:landuse%3Dbrownfield genau richtig. Was mache ich aber wenn Schrebergärten abgerissen wurden und nun eine Wiese vorhanden ist, welche noch dazu an einen Park angrenzt. Gebaut wird aber frühesten in einem Jahr. Das kommt drauf an, wie du die Aktualisierung einschätzt. Wenn Du sagst in den nächsten zwei Jahren komme ich nicht dazu zu überprüfen ob da jetzt ein Haus steht, andererseits keine andere Nutzung in betracht kommt, so halte ich brownfield für durchaus vertretbar. Das Contiloch[1] in Chemnitz existiert seit fast 20 Jahren und ich würde sagen, dass es ein brownfield ist, auch wenn sich mittlerweile seltene Arten ansiedeln, die jedem Naturschützer Freundentränen in die Augen treiben. Eine Wiederbebauung kommt nach wie vor in Betracht, falls nicht jemand die kleine Hufeisennase oder eine andere bedrohte Spezies entdeckt. Ich finde auch noch die ein oder andere Kohl-Sorte, auch ist am Pflanzenwuchs noch gut zu erkennen, wo Beete bzw Häuschen waren. Die Wiese wird jedoch eher schon als Park benutzt und ist öffentlich zugängig. Mal wieder ein Fall für landcover=* ? Martin freut sich bestimmt, wenn du das verwendest :-) Aber einen schönen Wert habe ich da auch nicht. Das wäre ja dann scrub, nur auf Krautebene :-) Vielleicht landcover=pioneer_species. Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach Elbufer, Bad Schandau
Am 18.04.2012 22:08, schrieb hike39: Es gab mal einen 229.000km² großen ALDI: http://www.openstreetmap.org/browse/way/124228864/history Der Fehler ist schon länger behoben und es wundert mich, dass er noch immer gefunden wird. Nominatim bei openstreetmap.org liefer mir als Ergebnis zwei Primärstraßen (Ostrau, Postelwitz), eine Almhütte und ein Haus, aber nirgends erscheint ALDI. Welche Suche hast du benutzt? Ganz einfach bei http://www.openstreetmap.de/karte.html?zoom=15lat=50.91107lon=14.17838layers=B000TT und dann in der Suchmaske Elbufer, Bad Schandau angeben. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Meine Suche stammt von openstreetmap.org, aber auch openstreetmap.de liefert bei mir keinen Aldi. Wie sieht es bei den anderen aus? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massenumbenennung Relationen von Multipolygon in Boundary
Am 19.04.2012 14:16, schrieb Frederik Ramm: Hallo, On 04/19/12 13:10, fly wrote: Es geht nicht um weltweite Edits sondern um regionale. Im konkreten Fall sind 418 Kreis- und 746 Stadtgrenzen betroffen. Ist das noch ein regionaler Edit? Bye Frederik Dafür hat er jetzt über 1000 Edits mehr in seiner Statistik, das wird seinem Ego schon was bringen. :X ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach Elbufer, Bad Schandau
Jimmy_K jimm...@gmx.at wrote: Meine Suche stammt von openstreetmap.org, aber auch openstreetmap.de liefert bei mir keinen Aldi. Seit 15:26 ist openstreetmap.de ebenfalls nominatim.osm.org siehe mein Posting in diesem thread, Wie sieht es bei den anderen aus? Diese Frage erübrigt sich damit. Sven -- In the land of the brave and the free, we defend our freedom with the GNU GPL (Richard M. Stallman on www.gnu.org) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Burgen, Schlösser usw ... ;-)
Am 19. April 2012 14:52 schrieb Sven Geggus li...@fuchsschwanzdomain.de: Manfred A. Reiter ma.rei...@gmail.com wrote: Das Problem ist wohl, dass es in der datenbank die Spalte ruins nicht gibt. Meine Datenbank hat ein hstore. Deshalb kann ich das vergleichsweise einfach einbauen. es geht ja vor allem um historic=castle, nicht nur um Ruinen, aber klar, diese Spezialtags (z.B. auch castle type) kann man nur schwer mit einer Datenbank ohne hstore abdecken. Vielleicht wäre es sinnvoller, relation_type einzuführen für Relationen, anstatt alle anderen type-Arten jeweils mit Doppelpunkten oder Unterstrichen zu subtaggen? Zumindest im klassischen Schema ohne hstore kommt man durch die wachsende Key-vielfalt schon länger an die Grenzen... Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] GPS mit *gutem* Empfang?
Manuel Reimer wrote: Kann jemand bestätigen, dass das Bluetooth beim iBlue747A+ tatsächlich nach einigen Minuten ohne Verbindung ausgeschaltet wird? Wie schon erwähnt wäre mir das schon wichtig, denn in den allermeisten Fällen werde ich kein Bluetooth brauchen und Akku-Laufzeit ist mir da dann doch wichtiger. Habe etwas gesucht und was ich rausfinden konnte, ist, dass Bluetooth garnicht auszuschalten geht, was ich schade finde. Stattdessen geht das Gerät irgendwann in eine Art Stromsparmodus für Bluetooth, in dem aber weiterhin mit Geräten verbunden werden kann. Sollte ich kein anderes Gerät mit MKT II Chipsatz finden, dass ähnliches bietet, dann ist der kleine Nachteil aber zu verschmerzen. Länger wie mein WBT 201 sollte er (wenn die Angaben stimmen) trotzdem durchhalten. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Großbaustelle
Am 19. April 2012 15:21 schrieb fly lowfligh...@googlemail.com: Was mache ich aber wenn Schrebergärten abgerissen wurden und nun eine Wiese vorhanden ist, welche noch dazu an einen Park angrenzt. Gebaut wird aber frühesten in einem Jahr. wenn die Wiese als solche zugänglich ist, würde ich landuse=meadow verwenden oder evtl. auch landuse=greenfield. Vormalige Schrebergärten rechtfertigen eine brownfield-Einstufung sicherlich nicht, man kann sie m.E. auch nicht als entwickeltes Gebiet bezeichnen (im Gegenteil, sind sie in aller Regel dort als meist temporäre Nutzung anzutreffen, wo eben gerade noch nichts entwickelt ist, oder wo sich aufgrund der räumlichen Gegebenheiten auch zukünftig nur schwer was entwickeln lässt, wie z.B. ungünstig geschnittene Restflächen neben Bahndämmen u.ä.). Sowohl greenfield als auch brownfield passen eigentlich sowieso nicht so ganz ins Schema, weil sie Landuseplanungen sind (also sich darauf beziehen, dass dort gebaut werden soll), und nicht die aktuelle Landnutzung beschreiben. Die wäre eher Industriebrache im Fall von brownfield oder Wiese im Fall von greenfield (oder Brache, falls die Wiese nicht gemäht wird). Ich finde auch noch die ein oder andere Kohl-Sorte, auch ist am Pflanzenwuchs noch gut zu erkennen, wo Beete bzw Häuschen waren. Die Wiese wird jedoch eher schon als Park benutzt und ist öffentlich zugängig. Mal wieder ein Fall für landcover=* ? leisure=park? landuse=meadow? landcover kann man natürlich immer verwenden, da es vom Rest unabhängig ist. Was ich vor kurzem entdeckt habe: http://wiki.openstreetmap.org/wiki/Key:habitat ist nicht gerade häufig in Gebrauch, könnte aber für Details zum Bewuchst vielleicht auch Anregungen bieten. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenbegleitende Radwege
Bernhard Weiskopf wrote: Straßenbegleitende Radwege mit den entsprechenden Schildern müssen von Radfahrern benutzt werden, hier setze ich zusätzlich an die Straße bicycle = no. Halte ich genauso. Ich erfasse den Regelfall, nicht seltene Sonderfälle wie Schnee auf dem Radweg. Sonst kommt der Nächste und entfernt alle maxspeed, denn die gelten schließlich nicht für Einsätze mit Sondersignal. Gibt es eine Möglichkeit, den Routern quasi eine Empfehlung (per tag o. ä.) für den meistens besser geeigneten, abgesetzten Weg mitzuteilen, oder müssen die Router damit alleine zurechtkommen? Ich denke die Router müssen das alleine schaffen. Wir erfassen einen _Zustand_, keine Empfehlungen. Schon deshalb nicht, weil jeder Fahrer andere Präferenzen hat und sich das Routing dementsprechend einstellt. Tschaui, Jörg -- There are only 10 types of people in the world: Those who understand binary, and those who don't... signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach Elbufer, Bad Schandau
On Thu, Apr 19, 2012 at 11:59:55AM +0200, Andreas Labres wrote: On 19.04.12 11:33, Martin Koppenhoefer wrote: [place=region] m.E. braucht man für diese klar definierten Verwaltungseinheiten überhaupt kein place, das ist mit admin_level und boundary=administrative hinreichend definiert. ACK. IMO sollte man dem Nominatim beibringen, dass es Staaten gibt, deren admin-boundaries mittlerweile halbwegs vollständig sind und daher diese gedachten Wolken um Place Nodes herum entbehrlich und kontraproduktiv sind! Man ist gerade dabei, dass Nominatim beizubringen. Es gibt noch ein paar kleinere Bugs zu bereinigen, aber das Ganze wird mit dem Neuimport nach dem Lizenzwechsel live gehen. Dann werden also place-Nodes und boundary-Relationen zusammengefasst und auch admin_center und label-Roles in den Boundary-Relationen berücksichtigt, was hoffentlich einen grossen Teil der Addressfehler beseitigen sollte. In AT gibt's dasselbe Theater, grade die Wolken um place=region scheinen mir zu groß gedacht und -- da es die Grenzhierarchie längst gibt - entbehlich. Nominatim kennt 25 place=region-Nodes in Österreich. Alle scheinen noch aus dem openGeoDB-Import zu stammen und Bezirke zu bezeichnen. Wenn ich mir [1] ansehe, scheinen österreichische Bezirke den deutschen Kreisen zu entsprechen (admin_level=6). Wie bereits gesagt, folgt Nominatim der Konvention, dass dieses level place=county entspricht. Es gibt also drei Möglichkeiten, das zu bereinigen. Ihr könnt die Nodes löschen, in place=county umtaggen oder einfach bis nach dem Lizenzwechsel warten, wo dann die region-Nodes ohnehin ignoriert werden. [1] http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative ACK. Das sollte man mal final spezifizieren (und auch in Mapnik+Nominatim umsetzen). In Wien (und das gilt so ähnlich auch in anderen größeren österr. Städten) gibt es a) (Stadt-/Gemeinde-)Bezirke (admin_level 9) b) Katastralgemeinden (hauptsächlich durch Place Nodes abgebildet; Grenzen zu erfassen wäre aber denkbar) c) Grätzelnamen (entspr. place=neighbourhood) Grade bei a) und b) (momentan beide als place=suburb gemappt, was äußerst unbefriedigend ist) wäre eine durchgängige Größen- und Ebenenunterscheidung wünschenswert, in der Beschriftung im Mapnik/Standardstil genauso wie im Nominatim (der sollte überhaupt nur a) berücksichtigen und b) und c) in seiner Hierarchie ignorieren...). Ich bin verwirrt, du erwartest, dass gleich getaggte place-Nodes unterschiedlich behandelt werden? Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach Elbufer, Bad Schandau
Am 19.04.2012 19:44, schrieb Sarah Hoffmann: Nominatim kennt 25 place=region-Nodes in Österreich. Alle scheinen noch aus dem openGeoDB-Import zu stammen und Bezirke zu bezeichnen. Wenn ich mir [1] ansehe, scheinen österreichische Bezirke den deutschen Kreisen zu entsprechen (admin_level=6). Wie bereits gesagt, folgt Nominatim der Konvention, dass dieses level place=county entspricht. Es gibt also drei Möglichkeiten, das zu bereinigen. Ihr könnt die Nodes löschen, in place=county umtaggen oder einfach bis nach dem Lizenzwechsel warten, wo dann die region-Nodes ohnehin ignoriert werden. [1] http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative Irgendwie verwirrt mich der Link gewaltig: admin_level=4: Bundesland http://de.wikipedia.org/wiki/Bundesland_%28%C3%96sterreich%29 NUTS2 was nun NUTS2 oder Bundesland (wäre NUTS3) admin_level=5: Region NUTS3 Regionen sind aber NUTS2 (Ost, Süd, West) oder NUTS4 (in etwa die Viertel Gehört aber wohl eher i talk-at ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Jahr der Errichtung - Ergänzung des Lübeck-Wiki
Hallo, Am Donnerstag, 19. April 2012 14:19:48 schrieb Martin Koppenhoefer: Am 19. April 2012 13:18 schrieb Wolfgang wolfg...@ivkasogis.de: -1 start_date ist zu allgemein und kann sich auch auf den Laden im Haus oder sonst was beziehen. -1 der Laden im Haus ist sowieso ein anderes Objekt als das Haus. Um das sauber abzubilden sollte man dafür nicht daselbe Objekt verwenden. Das gibt an allen Stellen nur Probleme, z.B. beim Namen, bei der Stockwerksanzahl, beim operator und überall sonst, wo nicht komplett klar ist, worauf sich der tag bezieht. Das kann man auf verschiedene Arten tun, z.B. indem der Laden als Node gemappt wird, oder indem man für das Gebäude einen way macht, der als outer in einem Laden- Multipolygon member ist (oder anders rum, wenn die Fläche jeweils genau gleich ist). Ich halte es für besser, solche Trennungen auch durch getrennte Objekte darzustellen, als die tags immer weniger universell einsetzbar zu machen, indem man ständig neue Verschachtelungen erfindet, die kaum jemand auswerten kann. -1 ;-) Normalerweise würde ich dir Recht geben, aber start_date für das Erstellungsdatum passt sprachlich einfach nicht. Ich glaube nicht, dass sich das durchsetzt. Zu den Trennungen: Häufig wird der Laden, der sich im Haus befindet, an das Gebäude getaggt, wenn es nur einer ist. Das mache nicht nur ich so. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenbegleitende Radwege
Hallo, Am Donnerstag, 19. April 2012 19:34:39 schrieb Joerg Fischer: Bernhard Weiskopf wrote: Straßenbegleitende Radwege mit den entsprechenden Schildern müssen von Radfahrern benutzt werden, hier setze ich zusätzlich an die Straße bicycle = no. Halte ich genauso. Ich erfasse den Regelfall, nicht seltene Sonderfälle wie Schnee auf dem Radweg. Sonst kommt der Nächste und entfernt alle maxspeed, denn die gelten schließlich nicht für Einsätze mit Sondersignal. Ist aber ganz einfach falsch. bicycle=designated ist das tag der Wahl. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenbegleitende Radwege
Auch wenn der Radweg unzumutbar ist, darf auf der Straße gefahren werden. Somit ist bicycle=no falsch (außer bei Verbotsschildern). +1 Es gibt ja auch Räder mit besonderen Ansprüchen (Liegedreirad, Anhänger, Rennrad). Die Zumutbarkeit entscheidet der Radfahrer selbst. Den Rest regelt die Rechtsschutzversicherung ;-) Für mich klingt die Beschreibung, z. B. zum Zeichen 237 (Radweg), eindeutig: Radfahrer dürfen nicht die Fahrbahn, sondern müssen den Radweg benutzen (Radwegbenutzungspflicht). (Quelle: StVO 2010-12-01) Radfahrer dürfen nicht übersetzte ich mit bicycle = no. Das trifft erfahrungsgemäß für die große Mehrheit der Radfahrer zu. Juristische Spitzfindigkeiten möchte ich aus OSM raushalten und geregelte Abweichungen würde ich in gesonderten tags unterbringen. Routingmäßig nervig wird das bicycle=no, wenn der Radweg nicht mit allen querenden Straßen (auch gegenüber) verbundne ist, ... Das muss der Mapper in der Tat dann genau beachten. Ich finde es sogar hilfreich, wenn mir der Routenplaner anzeigt, dass ich vom Radweg auf die Straße wechseln muss, um z. B. links abbiegen zu können. Wird die Route auf der Straße angezeigt und ich fahre ordnungsgemäß auf dem abgesetzten Radweg, kann ich nicht abbiegen. Bernhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenbegleitende Radwege
Gibt es eine Möglichkeit, den Routern quasi eine Empfehlung (per tag o. ä.) für den meistens besser geeigneten, abgesetzten Weg mitzuteilen, oder müssen die Router damit alleine zurechtkommen? Ich denke die Router müssen das alleine schaffen. Wir erfassen einen _Zustand_, keine Empfehlungen. Schon deshalb nicht, weil jeder Fahrer andere Präferenzen hat und sich das Routing dementsprechend einstellt. Tschaui, Jörg Ich dachte an eine einzige Default-Vorgabe für Straße meiden: wenn nicht anders gewünscht wird der Wirtschaftsweg o. ä. geroutet, also für alle die, die den parallelen Weg benutzen dürfen (z. B. Fußgänger, Radfahrer, Mofafahrer, Reiter, Traktoren) oder gezielt für einzelne Nutzertypen mit den bekannten access keys und einem neuen Wert, z. B. unwanted oder tolerated statt den üblichen (yes / designated / private / permissive / destination / delivery / agricultural / forestry / unknown / no). Ich wünsche mir Router, die die unterschiedlichen Wünsche der Radfahrer und Fußgänger berücksichtigen können, z. B. Gefährlichkeit, Oberflächenbeschaffenheit, Ampelfreiheit, Steigungen und vieles mehr. Bei http://www.openrouteservice.org/ kann man immerhin aus fünf Vorgaben auswählen, wobei die Algorithmen zum Routen sehr komplex werden können und immer noch nicht die optimale Route auswählen. Bernhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Moin, ich mag in diesem Zusammenhang noch einmal kurz auf das Thema Flächennetzwerk zurückzukommen. Have a fun read.. Am 19.04.2012 13:05, schrieb Wolfgang: -1 Das Multipolygon sollte rein Fläche bleiben, und Fläche sollte nur im Multipolygon erfasst werden. Wer was dazu sammeln will, kann das über eine site verbinden. Wieder das Thema Relationen verbiegen. Damit würdest Du z.B. sämtliche Parks als type=site Relationen erfassen, in denen Du dann die MP der Einzelflächen sammelst. Aber was ist überhaupt eine Einzelfläche? Betrachten wir beispielsweise einen Schlosspark bestehend aus mehreren Teichen, Rabatten, Wiesen, etc. die im Park verteilt sind - das Schloss selbst steht auf einem Sockel im Zentrum des Parks. 1. MP - Teiche 2. MP - Rabatten 3. MP - Wiesen 4. MP - Sockel 5. MP - Schloss Die ersten drei MP werden Löcher haben (alles mit ways in der Rolle inner machbar). Kommen wir zum Park, wir erstellen unsere type=site Relation, packen die ersten drei MP hinein und stellen uns dann die durchaus interessante Frage, ob das Schloss zum Schlosspark gehört, es demnach ebenfalls mit in die Sammelrelation aufgenommen werden sollte. Bevor wir diese Frage beantworten, stellen wir aber fest, dass mehrere der Teiche kleinere Inseln haben, wir splitten also die Teiche in 1.a. MP - Wasserflächen 1.b. MP - Inseln Man beachte, dass die Löcher lt. MP-Definition nicht zur Fläche gehören, also ist (1.a.) nicht das gleiche wie (1.). Nach deiner Einschätzung legen wir also (1.) neu an, als type=site Relation (1.neu.) type=site - name=Teiche Möchten wir nun unseren Park zusammenbauen, können wir das auf zwei Arten tun: type=site Mitglieder: MPs (1.a.) (1.b.) (2.) (3.) ... type=site Mitglieder: (1.neu.) + MPs (2.) (3.) ... Ich tendiere zu letzterer Variante, allerdings enthielte type=site dann eine Relation vom gleichen Typ. Wir beschäftigen uns also mit verschachtelten type=site Relationen. Das wir den Namen von type=multipolygon auf type=site ändern, verschleiert IMHO nur die Tatsache, dass auch Flächensammlungen nichts anderes sind als Flächen. Das geht übrigens schon aus der einfachen, bisherigen Definition von MP hervor. Betrachten wir z.B. das zweite MP des imaginären Schlossparks - die Rabatten. Schon dieses kann eine (Einzel-)Flächensammlung sein - je nachdem, wieviele Rabatten der Park hat. Die momentane Definition von Multipolygonen erlaubt es uns also, mehrere Flächen zusammenzufassen, solange sie gleichen Typs sind, sprich, solange der Mapper sie als zusammengehörig empfindet und sie mit den gleichen Tags beschreiben kann. Leider sind verschachtelte MP-Relationen (nestedMP) unpraktikabel, wenn es um die Berechnung der Fläche geht, die sich aus den Einzelflächen der Kinder und Kindeskinder (..) ergibt. Schließlich sind nur die outer/inner Mitglieder der Kinder und Kindeskinder (..) interessant, die tatsächlich einen Beitrag zu Außen- oder Innenringen des nestedMP liefern. Ab einer bestimmten Schachtelungstiefe wird die Grenzbestimmung daher unbeherrschbar - um die Flächengrenze eines nestedMP zu ermitteln, müssten alle Blätter des MP-Baumes durchsucht werden, also alle Relationen, die dann tatsächlich way-members als Mitglieder haben und nicht selbst ein nestedMP sind. Je tiefer dieser Baum, desto höher die Wahrscheinlichkeit, dass es mehr irrelevante members als relevante gibt. Bsp.: Kreisgrenzen und Landesgrenze - es gäbe 'zig innenliegende Kreisgrenzen, die für die Berechnung der Landesgrenze nicht relevant sind - deshalb macht es für die Berechnung der Grenzgeometrie keinen Sinn, die Landesgrenze über ein nestedMP mit allen Kreisgrenz-Relationen als Mitglieder zu erfassen. Dennoch interessiert evtl. der Flächenbezug der Kreisflächen zur Landesflächen in einem anderen Kontext. Beide Wünsche ließen sich vereinen. Um auf das Beispiel zurückzukommen: Ich kann mir auch den gesamten Park als Einzelfläche vorstellen, ohne die Grenzen der Rabatten, Teiche, Wiesen, etc. Weil ich das kann, möchte ich den Park auch als type=multipolygon anlegen und nicht als type=site (Anm.: type=site entspräche einem nestedMP, wenn man daraus die Geometrie der Gesamtfläche des Parks ermitteln will). Um mit der bestehenden Definition von MP zu arbeiten, würde ich also alle relevanten Mitglieder aus (1.) (2.) (3.) und evtl. (4.) und (5.), je nachdem ob das Schloss zum Schlosspark gehört oder nicht, ermitteln und diese in ein neues MP 6. MP - Schlosspark übertragen. Das geschieht händisch, nach Ermessen des Mappenden. Der einzige explizite Zusammenhang in OSMs Daten zwischen Schlosspark und zugehörigen Teilen (Wiesen, Teichen, Rabatten, etc.) wäre dann über die Flächengrenze des Schlossparks ersichtlich - eine komplett innenliegende Wiese, die sich keine Grenze mit Flächengrenzen des Schlossparks teilt, hätte keinen expliziten Zusammenhang in den Daten. Geht es nicht um die Geometrie, sondern einfach nur um
Re: [Talk-de] Jahr der Errichtung - Ergänzung des Lübeck-Wiki
Am 19. April 2012 21:54 schrieb Wolfgang wolfg...@ivkasogis.de: Zu den Trennungen: Häufig wird der Laden, der sich im Haus befindet, an das Gebäude getaggt, wenn es nur einer ist. Das mache nicht nur ich so. ich habe das auch schon gemacht, bin aber ein bisschen davon abgekommen. Wenn man Details hinzufügt ist es meistens besser, die einzelnen Objekte klar zu trennen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenbegleitende Radwege
Am 19. April 2012 22:01 schrieb Wolfgang wolfg...@ivkasogis.de: Hallo, Am Donnerstag, 19. April 2012 19:34:39 schrieb Joerg Fischer: Bernhard Weiskopf wrote: Straßenbegleitende Radwege mit den entsprechenden Schildern müssen von Radfahrern benutzt werden, hier setze ich zusätzlich an die Straße bicycle = no. Halte ich genauso. Ich erfasse den Regelfall, nicht seltene Sonderfälle wie Schnee auf dem Radweg. Sonst kommt der Nächste und entfernt alle maxspeed, denn die gelten schließlich nicht für Einsätze mit Sondersignal. Ist aber ganz einfach falsch. bicycle=designated ist das tag der Wahl. +1, die Radwege sind benutzungspflichtig wenn sie da hinführen, wo man hinfahren will, das ist was anderes als ein Verbot für Radfahrer auf der Straße. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Viel einfacher für Mapper und Datenverwerter sowohl beim Anlegen als auch für die zukünftige Pflege bei Daten im Vergleich zu einer site-relation als bunte Mischung aller möglichen Elemente und Bestandteile ist ein schlichtes Polygon, das die Gesamtfläche beschreibt. Bei umfriedeten Grundstücken kann man z.B. einen (im einfachsten Fall) way für Zaun/Mauer haben, der dann als outer einer Multipolygon-relation dient, die das Gesamtareal beschreibt. Alles Darinliegende (Schloßteich, Blumenrabatte, Mülltonnen und Hundekottütensp...) ist dann automatisch erstmal Bestandteil, sofern man es nicht explizit als inner way wieder ausschließt, eine Site braucht man dazu nicht. Ich würde in die site (falls man sie überhaupt benötigt für das, was man abbilden will) dann auch nicht unbedingt alle Einzelteile reintun, sondern dieses Gesamtobjekt. Für so was wie die Teiche in einem Schloßpark würde ich keine eigene site-Relation anlegen. Die von Dir beobachtete Verschachtelung, die Du gerne mit Relationen abbilden willst, ergibt sich bereits geometrisch aus den Daten, auch ohne jegliche Relation. Je einfacher man zum gewünschten Ergebnis kommt, um so besser. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach Elbufer, Bad Schandau
Oehm, wenn ich noch mal nachhaken duerfte: Im obigen Beispiel mit Fischmarkt, Erfurt war es osm.org, das mit Coburg einige hundert km daneben lag und osm.de, der sich nur im Nachbarkreis vertan hat. Das ist mit einem aktuellen Test uebrigens noch genauso (aber das kann auch an irgend welchem Caching liegen). Ist das auch mit den place nodes zu erklaeren? Gruss, Chaos ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] GPS mit *gutem* Empfang?
On 19.04.2012 18:28, Manuel Reimer wrote: Bluetooth beim iBlue747A+ tatsächlich nach einigen Minuten ohne Sollte ich kein anderes Gerät mit MKT II Chipsatz finden, dass ähnliches bietet, dann ist der kleine Nachteil aber zu verschmerzen. Länger wie mein WBT 201 sollte er (wenn die Angaben stimmen) trotzdem durchhalten. Der Akku im im iBlue ist baugleich zu den Nokia Handy-Akkus. Da könntest du wohl Ersatz mitnehmen. Habe es nicht genauer getestet aber ich habe gehört der Logger verliert Einstellungen wenn man die Batterie rausnimmt. Falls ich mal eine halbe Stunde habe werde ich das testen und im Wiki mit dokumentieren. Sonst kannst du ja auch unterwegs mit einer externen USB Batterie nachladen falls du weit ab von einer Steckdose bist. Download der Loggerdaten auf ein Android Smartphone funktioniert auch, damit hast du auch ohne PC in der Nähe quasi unbegrenzt Speicherplatz. Bist du in der Nähe München? Ich kann dir meinen Loger zum Testen ausleihen. Per Post verschicken lohnt sich nicht, bei ebay git es den Logger gebraucht für ca. 35 EUR. Viele Grüße, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-in] KPWD Interactive road map of Karnataka
http://www.kpwd.gov.in:8080/webris/webris I hadn't noticed that the Karnataka Public Works Dept. website hosted a fantastic map showing the major and minor roads of the state.. I'm not sure if the data can be used.. but it is a wonderful reference source for mapping the road network in the state.. ___ Talk-in mailing list Talk-in@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-in
Re: [Talk-it] video - osm/wikipedia
Creazione di mappe Foto binomio vincente! 2012/4/18, Simone Cortesi sim...@cortesi.com: Ciao, mi sono imbattuto in questo video, in cui, ad un certo punto si parla di OSM+wikimedia commons+wiki loves monuments: http://www.youtube.com/watch?feature=player_detailpagev=DDRkgsvhSoc#t=45s Ritengo che la mappa mostrata durante il video, sia questa: http://toolserver.org/~kolossos/openlayers/kml-on-ol.php?lang=itzoom=4lat=48.5166lon=5.71289layers=0B000TTTF -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] La mappa OSM di Wikipedia si migliora
Ottimo, grazie per le informazioni! Il 18/04/12, Otourly Wikiotou...@yahoo.fr ha scritto: Buongiorno a tutti, Scusi per il mio italiano. Su Wikipedia, da guigno 2011 c'è la mappa OSM nel angolo destra delle pagine di Wikipedia italiana. Dovete cliccare su (mappa) per vederla. Ma, dopo la migrazione CC-Y-SA → OBDL di OSM, ci sará una funzionalità in più. WIWOSM è un progetto che usa la chiave wikipedia o wikipedia:lang per mostrare la copertura della pagina della wikipedia. http://wiki.openstreetmap.org/wiki/WIWOSM Attualmente , questa funzionalità non è attivata su la wikipedia italiana, ma possiam vederla in azione sulla wikipedia in tedesco, cliccando su il link (Karte) Per essempio : http://de.wikipedia.org/wiki/Lyon Florian Farge aka Otourly Sur lesprojets wikimédiens et l'Association française,OSM, et sur MOVIM Socio di Wikimedia Italia ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] La mappa OSM di Wikipedia si migliora
Il 18 aprile 2012 17:43, Otourly Wiki otou...@yahoo.fr ha scritto: Buongiorno a tutti, Scusi per il mio italiano. Su Wikipedia, da guigno 2011 c'è la mappa OSM nel angolo destra delle pagine di Wikipedia italiana. Dovete cliccare su (mappa) per vederla. Ma, dopo la migrazione CC-Y-SA → OBDL di OSM, ci sará una funzionalità in più. WIWOSM è un progetto che usa la chiave wikipedia o wikipedia:lang per mostrare la copertura della pagina della wikipedia. http://wiki.openstreetmap.org/wiki/WIWOSM Attualmente , questa funzionalità non è attivata su la wikipedia italiana, ma possiam vederla in azione sulla wikipedia in tedesco, cliccando su il link (Karte) Per essempio : http://de.wikipedia.org/wiki/Lyon Ottimo! Un motivo in più per usare il tag wikipedia :-) Ciao, Simone ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] La mappa OSM di Wikipedia si migliora
Il 19/04/2012 10:41, Simone Saviolo ha scritto: Ottimo! Un motivo in più per usare il tag wikipedia :-) Io non ho ben capito cosa bisogna fare per far evidenziare in rosso le aree, come per Lione[1]. Ad esempio in Milano[2] sono indicati parecchi nodi che presentano il tag wikipedia, ma non l'area del comune. Grazie! Carlo [1] http://de.wikipedia.org/wiki/Lyon [2] http://de.wikipedia.org/wiki/Mailand -- .' `. | Registered Linux User #443882 |a_a | | http://counter.li.org/ .''`. \_)__/ +--- : :' : /( )\ ---+ `. `'` |\`/\ Registered Debian User #9 | `- \_|=='|_/ http://debiancounter.altervista.org/ | ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] La mappa OSM di Wikipedia si migliora
2012/4/19 Carlo Stemberger carlo.stember...@gmail.com: Ottimo! Un motivo in più per usare il tag wikipedia :-) Io non ho ben capito cosa bisogna fare per far evidenziare in rosso le aree, come per Lione[1]. Ho appena provato a mettere il tag wikipedia sulla relazione del comune di Milano, chissà se funziona? Ciao ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] La mappa OSM di Wikipedia si migliora
Il 19/04/2012 13:34, Federico Cozzi ha scritto: 2012/4/19 Carlo Stembergercarlo.stember...@gmail.com: Ottimo! Un motivo in più per usare il tag wikipedia :-) Io non ho ben capito cosa bisogna fare per far evidenziare in rosso le aree, come per Lione[1]. Ho appena provato a mettere il tag wikipedia sulla relazione del comune di Milano, chissà se funziona? Sì, può essere! Carlo -- .' `. | Registered Linux User #443882 |a_a | | http://counter.li.org/ .''`. \_)__/ +--- : :' : /( )\ ---+ `. `'` |\`/\ Registered Debian User #9 | `- \_|=='|_/ http://debiancounter.altervista.org/ | ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-co] Tuluá torcido!
Buenas tardes, hace un par de meses tal vez, compré un teléfono con Android y GPS (en parte motivado por el GPS), y después de probar algunas apps para guardar los puntos y obtener los archivos gpx, me quedé con GPSLogger: https://play.google.com/store/apps/details?id=com.mendhak.gpsloggerfeature=search_result#?t=W251bGwsMSwxLDEsImNvbS5tZW5kaGFrLmdwc2xvZ2dlciJd La cosa es que empece a hacer pruebas esta semana a ver podía usar el celular para ayudar a mejorar el mapa de Tuluá y cree una traza que subí al al wiki http://www.openstreetmap.org/user/Andphe/traces/1216942 , el problema es que en el mapa se ven mal ubicados los puntos, y en google maps esos puntos se ven bien. Cómo puede corregirse el asunto? imagino que deberían tomarse algunos puntos estratégicos para enderezar el mapa. Gracias, Andrés ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co
Re: [Talk-co] Tuluá torcido!
Y Guadalajara de Buga tambien Cordialmente, OSCAR RAMOS OVIEDO Programa de Crédito Comite de Cafeteros del Tolima Tel. Directo (8) 2615928 Conmutador (8) 2611622 ext. 119 Cel: 320 347 54 99 mail to: oscar.ra...@cafedecolombia.com De: Andrés F Vargas and...@gmail.com Para: OpenStreetMap Colombia talk-co@openstreetmap.org Fecha: 19/04/2012 01:16 p.m. Asunto: [Talk-co] Tuluá torcido! Buenas tardes, hace un par de meses tal vez, compré un teléfono con Android y GPS (en parte motivado por el GPS), y después de probar algunas apps para guardar los puntos y obtener los archivos gpx, me quedé con GPSLogger: https://play.google.com/store/apps/details?id=com.mendhak.gpsloggerfeature=search_result#?t=W251bGwsMSwxLDEsImNvbS5tZW5kaGFrLmdwc2xvZ2dlciJd La cosa es que empece a hacer pruebas esta semana a ver podía usar el celular para ayudar a mejorar el mapa de Tuluá y cree una traza que subí al al wiki http://www.openstreetmap.org/user/Andphe/traces/1216942 , el problema es que en el mapa se ven mal ubicados los puntos, y en google maps esos puntos se ven bien. Cómo puede corregirse el asunto? imagino que deberían tomarse algunos puntos estratégicos para enderezar el mapa. Gracias, Andrés ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co
Re: [Talk-co] Tuluá torcido!
hola si bien este asunto se lleva desde el año pasado (http://lists.openstreetmap.org/pipermail/talk-co/2011-April/thread.html#2082) aun deseariamos mas trazas si es posible, tambien hay una imagen de orbview3 pero notenemos un software GIS gratis que la interprete aun y con la que probe orbiew georeferenciado no sirve en los actuales GIS libres(pocos interpretan los datos orbview) voy a ver si consigo algunas trazas de la carretera para ayudar a tener mas referencia en eso harriercoTo: talk-co@openstreetmap.org From: oscar.ra...@cafedecolombia.com Date: Thu, 19 Apr 2012 14:54:13 -0500 Subject: Re: [Talk-co] Tuluá torcido! Y Guadalajara de Buga tambien Cordialmente, OSCAR RAMOS OVIEDO Programa de Crédito Comite de Cafeteros del Tolima Tel. Directo (8) 2615928 Conmutador (8) 2611622 ext. 119 Cel: 320 347 54 99 mail to: oscar.ra...@cafedecolombia.com De: Andrés F Vargas and...@gmail.com Para: OpenStreetMap Colombia talk-co@openstreetmap.org Fecha: 19/04/2012 01:16 p.m. Asunto: [Talk-co] Tuluá torcido! Buenas tardes, hace un par de meses tal vez, compré un teléfono con Android y GPS (en parte motivado por el GPS), y después de probar algunas apps para guardar los puntos y obtener los archivos gpx, me quedé con GPSLogger: https://play.google.com/store/apps/details?id=com.mendhak.gpsloggerfeature=search_result#?t=W251bGwsMSwxLDEsImNvbS5tZW5kaGFrLmdwc2xvZ2dlciJd La cosa es que empece a hacer pruebas esta semana a ver podía usar el celular para ayudar a mejorar el mapa de Tuluá y cree una traza que subí al al wiki http://www.openstreetmap.org/user/Andphe/traces/1216942 , el problema es que en el mapa se ven mal ubicados los puntos, y en google maps esos puntos se ven bien. Cómo puede corregirse el asunto? imagino que deberían tomarse algunos puntos estratégicos para enderezar el mapa. Gracias, Andrés ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co
Re: [Talk-co] Tuluá torcido!
Las imágenes Orbview3 (L1Gst) hay que descomprimirlas y tratarlas con este comando para reducir su tamaño: gdal_translate -ot Byte -scale -a_nodata 0 -co TILED=YES -co COMPRESSED=YES -co JPEG_QUALITY=85 inputfile outputfile1 Con esto pasan de 16 a 8 bit y de tiff a jpg Luego de eso pueden ser servidas con mapserser y tilecaché. ¿Quién nos apoya con este último punto? Un compañero con quien dialogar para aprender en pareja a realizarlo. El 19 de abril de 2012 19:31, Harrier Co harrie...@hotmail.com escribió: hola si bien este asunto se lleva desde el año pasado ( http://lists.openstreetmap.org/pipermail/talk-co/2011-April/thread.html#2082) aun deseariamos mas trazas si es posible, tambien hay una imagen de orbview3 pero notenemos un software GIS gratis que la interprete aun y con la que probe orbiew georeferenciado no sirve en los actuales GIS libres(pocos interpretan los datos orbview) voy a ver si consigo algunas trazas de la carretera para ayudar a tener mas referencia en eso harrierco -- To: talk-co@openstreetmap.org From: oscar.ra...@cafedecolombia.com Date: Thu, 19 Apr 2012 14:54:13 -0500 Subject: Re: [Talk-co] Tuluá torcido! Y Guadalajara de Buga tambien Cordialmente, OSCAR RAMOS OVIEDO Programa de Crédito Comite de Cafeteros del Tolima Tel. Directo (8) 2615928 Conmutador (8) 2611622 ext. 119 Cel: 320 347 54 99 mail to: oscar.ra...@cafedecolombia.com De: Andrés F Vargas and...@gmail.com Para: OpenStreetMap Colombia talk-co@openstreetmap.org Fecha: 19/04/2012 01:16 p.m. Asunto: [Talk-co] Tuluá torcido! -- Buenas tardes, hace un par de meses tal vez, compré un teléfono con Android y GPS (en parte motivado por el GPS), y después de probar algunas apps para guardar los puntos y obtener los archivos gpx, me quedé con GPSLogger: https://play.google.com/store/apps/details?id=com.mendhak.gpsloggerfeature=search_result#?t=W251bGwsMSwxLDEsImNvbS5tZW5kaGFrLmdwc2xvZ2dlciJd La cosa es que empece a hacer pruebas esta semana a ver podía usar el celular para ayudar a mejorar el mapa de Tuluá y cree una traza que subí al al wiki http://www.openstreetmap.org/user/Andphe/traces/1216942 , el problema es que en el mapa se ven mal ubicados los puntos, y en google maps esos puntos se ven bien. Cómo puede corregirse el asunto? imagino que deberían tomarse algunos puntos estratégicos para enderezar el mapa. Gracias, Andrés ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co
Re: [Talk-co] Tuluá torcido!
Hola de nuevo, 2012/4/19 Harrier Co harrie...@hotmail.com si bien este asunto se lleva desde el año pasado (http://lists.openstreetmap.org/pipermail/talk-co/2011-April/thread.html#2082) aun deseariamos mas trazas si es posible, tambien hay una imagen de orbview3 pero notenemos un software GIS gratis que la interprete aun y con la que probe orbiew georeferenciado no sirve en los actuales GIS libres(pocos interpretan los datos orbview) voy a ver si consigo algunas trazas de la carretera para ayudar a tener mas referencia en eso este fin de semana voy a intentar bordear la ciudad tanto como pueda, ademas de atravesarla de sur a norte y de oriente a occidente, eso debería dar un buen punto de partida. Andrés ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co
Re: [Talk-ar] Buenos Aires Data
lo de source es como dice Werner, lo que queda pendiente es el uso para administrativo publico que openstreetmap no tendria problemas, pero en esa licencia no se deja. Quizas con simplemente consultar si nos dejan subirlo a Openstreetmap bajo la licencia de Openstreetmap (algunos han hecho eso sin explicar demasiado) es suficiente. Saludos, Ignacio. 2012/4/19 Werner Horsch werner.hor...@gmail.com podemos usar la data, se puede aclarar en nuestra wiki el uso de la misma, agregar el tag source q solo lo puede ver un editor. Por más q alguién lo borre queda grabado el historial Con eso demostramos buena fé y q no hay intención de apropiarse de la misma 2012/4/18 Fernando cor...@fernando.com.ar ** Hola, Miren el API JS del USIG! servicios.usig.buenosaires.gob.ar/usig-js/2.2/doc/ Buenisimo. Quizá se pueda cruzar la data para vez faltantes en OSM. (no necesariamente para copiarlos automaticamente, sino para redibujar) Saludos. On 18/04/12 18:07, dan...@web.de wrote: Uah! Me muero - que increible cantidad de datos! Loco que los pongan bajo una licencia abierta. Pero, igual que como entiendo Ignacio, así como está dicho ahí ( http://data.buenosaires.gob.ar/about?s=terminos, se pone interesante bastante abajo bajo Política de licenciamiento de datos) pienso no es compatible con nuestra licencia. Primero: Nuestra licencia no excluye actividad administrativa pública. Entonces que podríamos hacer? Segundo: Lo de citar siempre la fuente y la fecha tampoco podemos garantizar. Ni ahí. Claro, se puede anadir un tag source=* etc. Pero el proximo usuario por ahi lo borra - y no podemos evitarlo. Y en los mapas derivados de OSM mucho menos podemos citar fuente y fecha. Yo la veo como Ignacio, preguntarles si para nosotros no pueden cambiar la licencia a PD u ODBL. Otra cosa, más técnica: No deberíamos hacer un *import *automatico de los datos. Trae muchos problemas, principalmente donde ya haya datos existentes. Más vale preparar los datos de tal manera que nosotros podamos copiar a mano, para que cada dato nuevo haya sido visto y controlado por una persona. Ojalá sea posible que utilizarlo! Sería buenísimo - encima para mí que no estoy en el lugar ;-) Saludos y hasta pronto, Daniel Am 23.03.2012 00:13, schrieb IgnacioZ: de cualquier manera quizas es cuestion de consultar si nos dejan. Teniendo en cuenta lo que saben de datos abiertos quizas conozcan Openstreetmap y no tengan ningun problema. Saludos, Ignacio. 2012/3/22 IgnacioZ zigna...@gmail.com Claro que esta muy bueno! Ahi estan todas las numeraciones, que esta faltando x casi toda capital. De cualquier manera, hay un punto que no se si se aplica en openstreetmap: 2. Su utilización con fines comerciales y no comerciales, *siempre que dicho uso no constituya una actividad administrativa pública.* Me suena raro, ya que ellos esta usando los datos. De cualquier manera, en teoria OSM se podria utilizar para cualquier cosa, incluida la actividad de la administracion publica. Saludos, Ignacio. 2012/3/22 hernan.lo...@gmail.com hernan.lo...@gmail.com Estuve mirando el nuevo sitio de la ciudad de buenos aires, Buenos Aires Data. Por lo que vi en la licencia de uso, se deberian poder usar los datos, solo piden que se mencione la fuente y la fecha de la fuente. Hay muchos datos ( http://data.buenosaires.gob.ar/dataset ) que puede ser piola que esten en OpenStreetMap, pero los archivos que facilitan, no son abiertos por Josm, por lo que vi. Entonces... Alguien que sepa mas sobre lo permitido o no, le puede dar una mirada a la licencia? Alguien sabe si josm puede importar los datos (es un zip con un .dbf, prj, shp, shp.xml, shx) mire los plugins, pero no me encontre nada en una primera mirada. O sea, sirve de algo? :) Saludos Hernan ___ Talk-ar mailing list Talk-ar@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ar ___ Talk-ar mailing listTalk-ar@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-ar ___ Talk-ar mailing listTalk-ar@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-ar ___ Talk-ar mailing list Talk-ar@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ar ___ Talk-ar mailing list Talk-ar@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ar ___ Talk-ar mailing list Talk-ar@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ar
Re: [Talk-ar] Buenos Aires Data
Lo de source sigo pensando que no hay problema. El tema es que el proyecto depende de que la gente actue de buena fe. Tranquilamente puede haber gente subiendo datos copiados de google que pasaria y si se descubre se revertirian los cambios. Este es un caso similar donde ponemos el source. De cualquier manera, por ahora sigue sin ser compatible x el otro tema. Alguien se anima a mandarles un mail? Si no hay voluntarios yo no tengo problemas, pero si alguien quiere y quizas conozco un poco el mecanismo que lo haga. Saludos! Ignacio. 2012/4/19 dan...@web.de También me parece que no es compatible. Es loco permitir uso comercial, pero no administrativo. Pero todavia no estoy de acuerdo con que podamos usar sin mas. Lo de la fuente y la fecha no tiene que estar sólo en el historial (donde, sin duda, nunca se borraría), sino dice: Deben conservarse, y por tanto no alterarse ni suprimirse los metadatos sobre la fecha de actualización y las condiciones de reutilización aplicables incluidos, en su caso, en el documento puesto a disposición para su utilización o reutilización. O sea: Todos los documento derivados de OSM tienen que tener estos metadatos. No funca. Pienso que nos permitirían usarlo, pero IMHO con esta licencia no da. Valdría la pena preguntar. Yo no quiero hacerlo pq pienso que sería mejor que un argentino lo haga. Saludos, Daniel Am 19.04.2012 06:23, schrieb Fajro: 2012/4/18 dan...@web.de dan...@web.de: Pero, igual que como entiendo Ignacio, así como está dicho ahí (http://data.buenosaires.gob.ar/about?s=terminos, se pone interesante bastante abajo bajo Política de licenciamiento de datos) pienso no es compatible con nuestra licencia. Me parece que esos términos de uso ni siquiera son compatibles con la definición de Conocimiento Abierto de la Open Knowledge Foundation que dicen estar usando: http://opendefinition.org/okd/espanol/ Fijense que el último parrafo del punto II de los Terminos y condiciones violaría el punto 4 de la definición de la OKF. Y el punto 2 del punto II de la sección Politica de licenciamiento de datos creo que también podría ser incompatible con el punto 8 de la definición. ___ Talk-ar mailing list Talk-ar@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ar ___ Talk-ar mailing list Talk-ar@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ar
Re: [Talk-ar] Buenos Aires Data
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 El 18/04/12 18:16, Fernando escribió: Hola, Miren el API JS del USIG! servicios.usig.buenosaires.gob.ar/usig-js/2.2/doc/ Buenisimo. Quizá se pueda cruzar la data para vez faltantes en OSM. (no necesariamente para copiarlos automaticamente, sino para redibujar) Saludos. yo use la api de la usig en el me gcba sobre todo para normalizar/validar nombre de calles con sus alturas es muy bueno. no vi todavia cuanto mas completaron desde el año pasado que la estuve usando en un par de apps. pero tenes mucha info. lo ideal seria que gcba cargue toda su info en osm y luego la use desde ahi como fuente de datos, que le agreguen un par de capas y listo! - -- Fernando Toledo Dock Sud BBS http://bbs.docksud.com.ar telnet://bbs.docksud.com.ar -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+Q5nIACgkQrka4e4h7i+MlWQCdFRCxvBvr1c+ysLptr33fbNe7 0ewAn19AJyDM/OQhPgfhCKk+6h8UCtM/ =CMlE -END PGP SIGNATURE- ___ Talk-ar mailing list Talk-ar@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ar
Re: [Talk-at] Admin-Rechte
Es scheint doch, dass es nicht so abwegig wäre das Land Salzburg anders zu bezeichnen als die Stadt da laut Nominatim viele oder alle Salzburger Berge beispielsweise unter Salzburg (Stadt) als Kinder angeführt werden. Es dürfte da einige falsche Zuordnungen entstanden sein. Woher bei der Anzeige der Karte in Nominatim die angezeigte Ellipse kommt anstelle der Grenze? Was ist der Unterschied zwischen Bundesland und Verwaltungsgrenze? LG, Peter. Am 18.04.2012 20:39, schrieb Jimmy_K: Am 17.04.2012 17:18, schrieb Peter Kössler: Danke für die bisherigen Antworten, mir geht es darum dass ich bei der Suche nach Salzburg z.B. bei Facilmap auf 3 Ergebnisse stoße wovon 2 Punkte im Pongau sind (boundary, place), nur der Dritte die Lage des Stadtnamens ergibt (aber ebenfalls mit place). Dann ist dies aber ein Fehler von Facilmap und nicht über die OSM Datenbank zu korrigieren. Die Suche bei Nominatim gibt für Salzburg aus: * Bundesland/-staat Salzburg, Österreich, Europa http://www.openstreetmap.org/?minlon=10.69minlat=44.857maxlon=15.81maxlat=49.977 * Verwaltungsgrenze Salzburg, Österreich, Europa http://www.openstreetmap.org/?minlon=12.0767478942871minlat=46.9438591003418maxlon=13.9961252212524maxlat=48.0403099060059 * Stadt Salzburg, Bezirk Salzburg, Gmunden, Salzburg, Österreich, Europa http://www.openstreetmap.org/?minlon=13.031058540344minlat=47.790197601318maxlon=13.051059494019maxlat=47.810201416016 und somit verwundert mich nur die Verwaltungsgrenze, denn sie liefert wirklich mittem in nichts einen Schriftzug: Salzburg http://www.openstreetmap.org/?lat=47.38992lon=13.0863zoom=17layers=M ___ 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
[Talk-at] Bezirkszusammenlegungen Steiermark
http://derstandard.at/1334795578210/Bezirksreform-Steiermark-macht-aus-sechs-Bezirken-drei Gibt wohl bald die Arbeit ein paar Grenzen zu überarbeiten ;) ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Bezirkszusammenlegungen Steiermark
Ja die Staatsgrenze wird ja auch modifiziert... Am 19. April 2012 11:02 schrieb Soldier Boy soldierboy2...@gmail.com: http://derstandard.at/1334795578210/Bezirksreform-Steiermark-macht-aus-sechs-Bezirken-drei Gibt wohl bald die Arbeit ein paar Grenzen zu überarbeiten ;) ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at -- Lukas Bischof p: +43 (664) 416 84 34 w: http://www.wordy-rappinghood.net/ @: lukas.bisc...@gmail.com ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Bezirkszusammenlegungen Steiermark
Was wird an der Staatsgrenze geändert? Bekommen wir endlich Bayern und Südtirol und geben dafür Burgenland ab? :P Am 19. April 2012 11:07 schrieb Lukas Bischof lukas.bisc...@gmail.com: Ja die Staatsgrenze wird ja auch modifiziert... Am 19. April 2012 11:02 schrieb Soldier Boy soldierboy2...@gmail.com: http://derstandard.at/1334795578210/Bezirksreform-Steiermark-macht-aus-sechs-Bezirken-drei Gibt wohl bald die Arbeit ein paar Grenzen zu überarbeiten ;) ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at -- Lukas Bischof p: +43 (664) 416 84 34 w: http://www.wordy-rappinghood.net/ @: lukas.bisc...@gmail.com ___ 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-at] Admin-Rechte
On 19.04.12 09:41, Peter Kössler wrote: Woher bei der Anzeige der Karte in Nominatim die angezeigte Ellipse kommt anstelle der Grenze? Im Anfang waren Place Nodes. Und Nominatim hat versucht, eine Koordinate dadurch einzuordnen, dass er eben auf jeder Ebenen nach dem nächstpassenden Node gesucht hat. Mittlerweile gibt es aber die Verwaltungsgrenzen. Und Nominatim sollte, speziell für AT und DE, die Place Nodes weitgehendst ignorieren. Das ist aber noch nicht perfekt umgesetzt. Letztlich sollte man das im Nominatim fixen... /al ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Admin-Rechte
Am 19.04.2012 12:07, schrieb Andreas Labres: On 19.04.12 09:41, Peter Kössler wrote: Woher bei der Anzeige der Karte in Nominatim die angezeigte Ellipse kommt anstelle der Grenze? Im Anfang waren Place Nodes. Und Nominatim hat versucht, eine Koordinate dadurch einzuordnen, dass er eben auf jeder Ebenen nach dem nächstpassenden Node gesucht hat. Mittlerweile gibt es aber die Verwaltungsgrenzen. Und Nominatim sollte, speziell für AT und DE, die Place Nodes weitgehendst ignorieren. Das ist aber noch nicht perfekt umgesetzt. Letztlich sollte man das im Nominatim fixen... /al ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at Da es gerade in talk-de um ein ähnliches Thema ging: es ist angeblich so gut wie gefixt. ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[Talk-ca] nominatum search seems to add postal code info, but from where?
Hello, If I do an arbitrary search for xxx, kitchener, ontario the results always include a guessed? postal code. Where is the postal code information coming from? Bill ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] nominatum search seems to add postal code info, but from where?
On Thu, Apr 19, 2012 at 12:22 PM, William Rieck bi...@thinkers.org wrote: Hello, If I do an arbitrary search for xxx, kitchener, ontario the results always include a guessed? postal code. Where is the postal code information coming from? geocoder.ca http://geocoder.ca/?sued=1 ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[OSM-talk-fr] Parc National des Calanques
Le décret http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT25708543 de création du Parc National des Calanques est paru ! Je me charge de le créer dans la base OSM. Damouns ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Parc National des Calanques
Rectification : les coordonnées en annexe du décret ne concernent que la partie maritime... pour la partie terrestre, comme souvent, les cartes peuvent être consultés au ministère de l’écologie [...], à la préfecture des Bouches-du-Rhône, à la préfecture du Var, au siège de l’établissement public du parc ainsi que dans les mairies des communes concernées. Je vais donc devoir attendre que les contours soient diffusés par le MNHN. Snif ! Le 19 avril 2012 09:07, Damouns damo...@gmail.com a écrit : Le décret http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT25708543 de création du Parc National des Calanques est paru ! Je me charge de le créer dans la base OSM. Damouns ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modèle de tags pour l'ajout des points de contacts de La Poste (était : La Poste publie la liste...)
2012/4/19 Vincent de Chateau-Thierry v...@laposte.net: libelle_site = name=* (en changeant la casse) Là il y a risque de conflit avec le name du commerçant, dans le cas du relais de poste. Dans ce cas particulier, il ne faudrait pas proposer de tag name mais : = soit le passer en post_office:name = soit le passer en note pour aider au repérage = soit l'ignorer (dommage) = soit...? On pourrait utiliser aussi 2 nodes. Mais on perd l'avantage de tagguer les points communs comme le numéro de téléphone et les heures d'ouverture. Je serais finalement plus pour la solution de ne garder que le nom du commerçant (ou de l'entité administrative, c'est parfois la mairie elle-même). Le tag name représente alors le vrai nom de l'endroit et l'activité relai-poste ne figure que dans le tag amenity. caracteristique_site: null = amenity=post_office AGENCE POSTALE COMMUNALE = amenity=post_office + 2e tag (post_office=* ?) RELAIS POSTE COMMERCANT = amenity=post_office + 2e tag (post_office=convenience ou post_office=restaurant avec l'aide du complement_adresse ?) Pour le 2e tag dans le cas d'une agence communale, je sèche. Moi aussi. C'est le même opérateur. Ce qui change uniquement, c'est le personnel qui n'est pas employé directement par la poste Pour le 2e tag dans le cas des relais commerçants : il existe 2 occurrences de post_office:type=post_partner : http://taginfo.openstreetmap.org/tags/post_office%3Atype=post_partner pourquoi pas À chaque fois ce sont des objets taggués par ailleurs en shop=* Ca n'est pas toujours des commerces (maisons de retraites, mairies) addr:postcode est le seul évident :-) J'évite de le mettre pour éviter les répétitions (sera tôt ou tard dans la relation commune) Pour le reste, le champ Adresse part dans tous les sens : rue, n°+rue, lieu-dit, caserne, route nationale, ... Il est précieux pour aider à localiser le bureau de poste, mais je n'en ferais pas un tag (sauf une autre note, pour un affinage de placement ultérieur, si le contenu OSM ne permet pas de bien positionner le point pour l'instant). Ok dans une note. C'est vrai que le champ est loin d'être complet sur l'ensemble de la liste. changeur_monnaie = amenity=change_machine ? photocopieur = amenity=copy_facility ? 1 dans taginfo ! Vu son âge (2008), c'est peut-être un copyshop qui s'ignore :-) Va pour ça. Je pourrais aussi demander sur la liste de diffusion tagging. monnaie_paris = ? Il y en a quand même plus de 2600 avec monnaie_paris=Oui... = tourism=souvenir ? (0 dans taginfo) Trop vague. On pourrait croire qu'ils vendent des tours Eiffel ! (ça viendra peut-être un jour) Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modèle de tags pour l'ajout des points de contacts de La Poste (était : La Poste publie la liste...)
Le 19 avril 2012 09:52, Pieren pier...@gmail.com a écrit : 2012/4/19 Vincent de Chateau-Thierry v...@laposte.net: libelle_site = name=* (en changeant la casse) Là il y a risque de conflit avec le name du commerçant, dans le cas du relais de poste. Dans ce cas particulier, il ne faudrait pas proposer de tag name mais : = soit le passer en post_office:name = soit le passer en note pour aider au repérage = soit l'ignorer (dommage) = soit...? On pourrait utiliser aussi 2 nodes. Mais on perd l'avantage de tagguer les points communs comme le numéro de téléphone et les heures d'ouverture. Je serais finalement plus pour la solution de ne garder que le nom du commerçant (ou de l'entité administrative, c'est parfois la mairie elle-même). Le tag name représente alors le vrai nom de l'endroit et l'activité relai-poste ne figure que dans le tag amenity. post_office:name me semble la meilleure approche. Ainsi on garde le libelle de la Poste, et on ne vient pas interférer avec un name pré-existant ou pas. De plus le libellé de la Poste n'est pas très parlant et a même besoin d'être remis en forme, par exemple: BELLEGARDE SUR VALSERINE PAL - Bellegarde sur Valserine (principale) Je le garderai donc tel qu'il est, sans retraitement et en post_office:name Pour ces agences postales ou relais, je ne suis pas sûr que de mixer avec l'autre POI soit une bonne idée. Les horaires d'ouverture peuvent être les même (ou pas), pareil pour le téléphone, il peut être identique ou différent (il existe des mini bureaux de poste dans une pièce séparée d'une épicerie ou d'un bar-resto), le tag operator peut déjà être utilisé (exemple d'un relais de poste dans un épicerie de chaine comme Proxy, Shoppy ou autre). En fait on a 2 service (amenity) différents, dans un même bâtiment... je suis plus attiré par la solution à 2 POI. caracteristique_site: null = amenity=post_office AGENCE POSTALE COMMUNALE = amenity=post_office + 2e tag (post_office=* ?) RELAIS POSTE COMMERCANT = amenity=post_office + 2e tag (post_office=convenience ou post_office=restaurant avec l'aide du complement_adresse ?) Pour le 2e tag dans le cas d'une agence communale, je sèche. Moi aussi. C'est le même opérateur. Ce qui change uniquement, c'est le personnel qui n'est pas employé directement par la poste Pour le 2e tag dans le cas des relais commerçants : il existe 2 occurrences de post_office:type=post_partner : http://taginfo.openstreetmap.org/tags/post_office%3Atype=post_partner pourquoi pas Pas mal ce post_office:type=post_partner Il peut aussi servir à indiquer les post_office:type=main (exemple de Bellegarde principale ci dessus, même cas de figure dans ma commune: 5 bureaux de poste, dont 1 principal connu comme la poste principale et 2 distributeurs... qui ont chacun leur code postal 94100 et 94210). À chaque fois ce sont des objets taggués par ailleurs en shop=* Ca n'est pas toujours des commerces (maisons de retraites, mairies) addr:postcode est le seul évident :-) J'évite de le mettre pour éviter les répétitions (sera tôt ou tard dans la relation commune) La redondance permet la vérification de cohérence... et aussi à un (semi) bot de proposer le codes postaux à mettre à jour dans les relations. +1 pour le reste Pensons bien aux cas particuliers... ce sont ceux qui vont faire que le modèle est bon ou pas ;) -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Parc National des Calanques
j'ai un amis qui travaille au GIP des calanques et à qui j'ai parlé d'une aventuelle ouverte des données produites, je vais voir s'il ets possible de rajouter ce genre de contours dans la liste ;) Sylvain Le 19 avril 2012 09:42, Damouns damo...@gmail.com a écrit : Rectification : les coordonnées en annexe du décret ne concernent que la partie maritime... pour la partie terrestre, comme souvent, les cartes peuvent être consultés au ministère de l’écologie [...], à la préfecture des Bouches-du-Rhône, à la préfecture du Var, au siège de l’établissement public du parc ainsi que dans les mairies des communes concernées. Je vais donc devoir attendre que les contours soient diffusés par le MNHN. Snif ! Le 19 avril 2012 09:07, Damouns damo...@gmail.com a écrit : Le décret http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT25708543 de création du Parc National des Calanques est paru ! Je me charge de le créer dans la base OSM. Damouns ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] La Poste publie la liste de ses points de contacts en licence ouverte sur data.gouv.fr
Le mer. 18 avril 2012 à 23:44 +0200, Pieren a ecrit : 2012/4/18 Vincent de Chateau-Thierry v...@laposte.net: Et il faut un minimum se pencher sur le modèle des tags à appliquer à ces données Une ébauche: Identifiant = ref:LaPoste ? (ref:Poste_FR pourrait poser problème s'il y a d'autres opérateurs) Je penche pour ref:FR:LaPoste ; il me semble que si tout le monde multiplie les imports, ça sera pratique d'avoir un niveau de contexte, à la fois pour diminuer le risque de collision (espace de nommage) et pour donner une idée rapide de l'étendue de la couverture des données. -- ° /\Guillaume AllègreOpenStreetMap France /~~\/\ allegre.guilla...@free.fr Cartographie libre et collaborative / /~~\tél. 04.76.63.26.99 http://www.openstreetmap.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
