Re: [Talk-hr] Promocija Splitske USE-IT karte temeljene na OSM podatcima
Zagrebačka promocija karte Splita je danas 26.02.2014. u 17h u KSET-u. Ako nekog interesira :D On 01/18/2014 03:17 PM, hbogner wrote: http://infozona.hr/news/ovako-se-turist-pretvara-u-splicu/6586 Di izlazimo, di jedemo, zašto žugamo, šta nam znače zidići... Koja je razlika između Kraševih slatkiša i rodbine, kako se lokalci ponašaju u prometu, kako krafne i burek potiču jedinstvo u raznolikosti... To su samo neka od pitanja na koja odgovor možeš provjeriti u četvrtak, 23. siječnja, od 20 sati u klubu Quasimodo na tulumu povodom izlaska prve splitske USE-IT mape. To može biti prilika lokalnim maperima za okupljanje, ako hoćete možete se naći ranije ako je nekom termin promocije kasno... Uglavnom prepuštam lokalnoj ekipi da se dogovori oko toga. PS. Znam da na karti fale staze i stepenice, ali tražili su da ih maknem jer im je bilo pregusto. U koliko dana je karografija odrađena ovo je super, za godinu/dvije ide reizdanje karte pa će za ond abiti više vremena za pripremu i izradu. Pozdrav ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Promocija Splitske USE-IT karte temeljene na OSM podatcima
Dosta smo loši u ovim pohađanjima :D Ja ne mogu danas nikako.. Dana 26. veljače 2014. u 13:13 hbogner hbog...@gmail.com je napisao/la: Zagrebačka promocija karte Splita je danas 26.02.2014. u 17h u KSET-u. Ako nekog interesira :D On 01/18/2014 03:17 PM, hbogner wrote: http://infozona.hr/news/ovako-se-turist-pretvara-u-splicu/6586 Di izlazimo, di jedemo, zašto žugamo, šta nam znače zidići... Koja je razlika između Kraševih slatkiša i rodbine, kako se lokalci ponašaju u prometu, kako krafne i burek potiču jedinstvo u raznolikosti... To su samo neka od pitanja na koja odgovor možeš provjeriti u četvrtak, 23. siječnja, od 20 sati u klubu Quasimodo na tulumu povodom izlaska prve splitske USE-IT mape. To može biti prilika lokalnim maperima za okupljanje, ako hoćete možete se naći ranije ako je nekom termin promocije kasno... Uglavnom prepuštam lokalnoj ekipi da se dogovori oko toga. PS. Znam da na karti fale staze i stepenice, ali tražili su da ih maknem jer im je bilo pregusto. U koliko dana je karografija odrađena ovo je super, za godinu/dvije ide reizdanje karte pa će za ond abiti više vremena za pripremu i izradu. Pozdrav ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr
[Talk-hr] Karta spomenika
http://sapzagrebulupuh.wordpress.com/ Netko zna nešto o ovom? ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Promotivni OSM letak
Pozdrav mapperi Jel ovaj letak ok ili trebamo šta mjenjati? https://dl.dropboxusercontent.com/u/3220458/letak-a6.pdf Ako da javite do sutra. Pozdrav ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Promotivni OSM letak
Ok je za letak, dovoljno informacija. srijeda, 26. veljače 2014. korisnik hbogner hbog...@gmail.com napisao je: Pozdrav mapperi Jel ovaj letak ok ili trebamo šta mjenjati? https://dl.dropboxusercontent.com/u/3220458/letak-a6.pdf Ako da javite do sutra. Pozdrav ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr -- Svega što vrijedi Bog je stvorio malo, kako zlata tako i Hrvata. ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Promotivni OSM letak
Tekst je OK, no previše je teksta. Za letak bi trebalo biti više šareno a manje teksta. Npr. na naslovnici slika neka i samo kratko; mi kartiramo svijet pridruži nam se. A s druge strane tekst, ali kraći i link na wiki gdje mogu saznati više. On 26 Feb 2014 16:57, hbogner hbog...@gmail.com wrote: Pozdrav mapperi Jel ovaj letak ok ili trebamo šta mjenjati? https://dl.dropboxusercontent.com/u/3220458/letak-a6.pdf Ako da javite do sutra. Pozdrav ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Promotivni OSM letak
On 02/26/2014 05:14 PM, valent.turko...@gmail.com wrote: Tekst je OK, no previše je teksta. Za letak bi trebalo biti više šareno a manje teksta. Npr. na naslovnici slika neka i samo kratko; mi kartiramo svijet pridruži nam se. A s druge strane tekst, ali kraći i link na wiki gdje mogu saznati više. Sa osm-hr.org imaju linkna wiki Jel ti se da složi svoju verziju? Mogu ti dati scribus fajl- preradu, nalazi se u dropboxu, a mogu ti dati i corel file ako jos postoji negdje. evo i nekog svg ekstrakta, neznam kako je to tocno kreirano :D https://dl.dropboxusercontent.com/u/3220458/letak_a6_v0.1-1.svg https://dl.dropboxusercontent.com/u/3220458/letak_a6_v0.1-2.svg evo i slika: https://dl.dropboxusercontent.com/u/3220458/qr-osm.png https://dl.dropboxusercontent.com/u/3220458/qr-osmhr.png https://dl.dropboxusercontent.com/u/3220458/200px-Logo_Croatia.svg.png https://dl.dropboxusercontent.com/u/3220458/Logo_Croatia.svg https://dl.dropboxusercontent.com/u/3220458/osm_logo.png Ja u ovom trenutku nestignem, a sutra bi to tiskao jer mi treba uskoro. Svi mogu pomoći ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Promotivni OSM letak
Vedran je u FB grupi stavio jedan primjer pa pogledajte https://www.facebook.com/groups/541098862671461/ https://fbcdn-sphotos-c-a.akamaihd.net/hphotos-ak-prn2/t1/1902793_10152198568368346_1997549752_n.jpg ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Promotivni OSM letak
Može. On 26 Feb 2014 17:29, hbogner hbog...@gmail.com wrote: On 02/26/2014 05:14 PM, valent.turko...@gmail.com wrote: Tekst je OK, no previše je teksta. Za letak bi trebalo biti više šareno a manje teksta. Npr. na naslovnici slika neka i samo kratko; mi kartiramo svijet pridruži nam se. A s druge strane tekst, ali kraći i link na wiki gdje mogu saznati više. Sa osm-hr.org imaju linkna wiki Jel ti se da složi svoju verziju? Mogu ti dati scribus fajl- preradu, nalazi se u dropboxu, a mogu ti dati i corel file ako jos postoji negdje. evo i nekog svg ekstrakta, neznam kako je to tocno kreirano :D https://dl.dropboxusercontent.com/u/3220458/letak_a6_v0.1-1.svg https://dl.dropboxusercontent.com/u/3220458/letak_a6_v0.1-2.svg evo i slika: https://dl.dropboxusercontent.com/u/3220458/qr-osm.png https://dl.dropboxusercontent.com/u/3220458/qr-osmhr.png https://dl.dropboxusercontent.com/u/3220458/200px-Logo_Croatia.svg.png https://dl.dropboxusercontent.com/u/3220458/Logo_Croatia.svg https://dl.dropboxusercontent.com/u/3220458/osm_logo.png Ja u ovom trenutku nestignem, a sutra bi to tiskao jer mi treba uskoro. Svi mogu pomoći ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Promotivni OSM letak
Draft ideja za prednju stranicu: http://i.imgur.com/jWRj1Ic.png 2014-02-26 22:28 GMT+01:00 valent.turko...@gmail.com valent.turko...@gmail.com: Može. On 26 Feb 2014 17:29, hbogner hbog...@gmail.com wrote: On 02/26/2014 05:14 PM, valent.turko...@gmail.com wrote: Tekst je OK, no previše je teksta. Za letak bi trebalo biti više šareno a manje teksta. Npr. na naslovnici slika neka i samo kratko; mi kartiramo svijet pridruži nam se. A s druge strane tekst, ali kraći i link na wiki gdje mogu saznati više. Sa osm-hr.org imaju linkna wiki Jel ti se da složi svoju verziju? Mogu ti dati scribus fajl- preradu, nalazi se u dropboxu, a mogu ti dati i corel file ako jos postoji negdje. evo i nekog svg ekstrakta, neznam kako je to tocno kreirano :D https://dl.dropboxusercontent.com/u/3220458/letak_a6_v0.1-1.svg https://dl.dropboxusercontent.com/u/3220458/letak_a6_v0.1-2.svg evo i slika: https://dl.dropboxusercontent.com/u/3220458/qr-osm.png https://dl.dropboxusercontent.com/u/3220458/qr-osmhr.png https://dl.dropboxusercontent.com/u/3220458/200px-Logo_Croatia.svg.png https://dl.dropboxusercontent.com/u/3220458/Logo_Croatia.svg https://dl.dropboxusercontent.com/u/3220458/osm_logo.png Ja u ovom trenutku nestignem, a sutra bi to tiskao jer mi treba uskoro. Svi mogu pomoći ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr -- follow me - www.twitter.com/valentt http://kernelreloaded.blog385.com linux, anime, spirituality, wireless, scuba, linuxmce smart home, zwave ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turko...@hotmail.com ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Promotivni OSM letak
Evo sitnih izmjena: http://i.imgur.com/70zBitX.png 2014-02-26 22:32 GMT+01:00 valent.turko...@gmail.com valent.turko...@gmail.com: Draft ideja za prednju stranicu: http://i.imgur.com/jWRj1Ic.png 2014-02-26 22:28 GMT+01:00 valent.turko...@gmail.com valent.turko...@gmail.com: Može. On 26 Feb 2014 17:29, hbogner hbog...@gmail.com wrote: On 02/26/2014 05:14 PM, valent.turko...@gmail.com wrote: Tekst je OK, no previše je teksta. Za letak bi trebalo biti više šareno a manje teksta. Npr. na naslovnici slika neka i samo kratko; mi kartiramo svijet pridruži nam se. A s druge strane tekst, ali kraći i link na wiki gdje mogu saznati više. Sa osm-hr.org imaju linkna wiki Jel ti se da složi svoju verziju? Mogu ti dati scribus fajl- preradu, nalazi se u dropboxu, a mogu ti dati i corel file ako jos postoji negdje. evo i nekog svg ekstrakta, neznam kako je to tocno kreirano :D https://dl.dropboxusercontent.com/u/3220458/letak_a6_v0.1-1.svg https://dl.dropboxusercontent.com/u/3220458/letak_a6_v0.1-2.svg evo i slika: https://dl.dropboxusercontent.com/u/3220458/qr-osm.png https://dl.dropboxusercontent.com/u/3220458/qr-osmhr.png https://dl.dropboxusercontent.com/u/3220458/200px-Logo_Croatia.svg.png https://dl.dropboxusercontent.com/u/3220458/Logo_Croatia.svg https://dl.dropboxusercontent.com/u/3220458/osm_logo.png Ja u ovom trenutku nestignem, a sutra bi to tiskao jer mi treba uskoro. Svi mogu pomoći ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr -- follow me - www.twitter.com/valentt http://kernelreloaded.blog385.com linux, anime, spirituality, wireless, scuba, linuxmce smart home, zwave ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turko...@hotmail.com -- follow me - www.twitter.com/valentt http://kernelreloaded.blog385.com linux, anime, spirituality, wireless, scuba, linuxmce smart home, zwave ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turko...@hotmail.com ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Promotivni OSM letak
Evo i verzija s logom: http://i.imgur.com/kaO8Cjs.png 2014-02-26 22:56 GMT+01:00 valent.turko...@gmail.com valent.turko...@gmail.com: Evo sitnih izmjena: http://i.imgur.com/70zBitX.png 2014-02-26 22:32 GMT+01:00 valent.turko...@gmail.com valent.turko...@gmail.com: Draft ideja za prednju stranicu: http://i.imgur.com/jWRj1Ic.png 2014-02-26 22:28 GMT+01:00 valent.turko...@gmail.com valent.turko...@gmail.com: Može. On 26 Feb 2014 17:29, hbogner hbog...@gmail.com wrote: On 02/26/2014 05:14 PM, valent.turko...@gmail.com wrote: Tekst je OK, no previše je teksta. Za letak bi trebalo biti više šareno a manje teksta. Npr. na naslovnici slika neka i samo kratko; mi kartiramo svijet pridruži nam se. A s druge strane tekst, ali kraći i link na wiki gdje mogu saznati više. Sa osm-hr.org imaju linkna wiki Jel ti se da složi svoju verziju? Mogu ti dati scribus fajl- preradu, nalazi se u dropboxu, a mogu ti dati i corel file ako jos postoji negdje. evo i nekog svg ekstrakta, neznam kako je to tocno kreirano :D https://dl.dropboxusercontent.com/u/3220458/letak_a6_v0.1-1.svg https://dl.dropboxusercontent.com/u/3220458/letak_a6_v0.1-2.svg evo i slika: https://dl.dropboxusercontent.com/u/3220458/qr-osm.png https://dl.dropboxusercontent.com/u/3220458/qr-osmhr.png https://dl.dropboxusercontent.com/u/3220458/200px-Logo_Croatia.svg.png https://dl.dropboxusercontent.com/u/3220458/Logo_Croatia.svg https://dl.dropboxusercontent.com/u/3220458/osm_logo.png Ja u ovom trenutku nestignem, a sutra bi to tiskao jer mi treba uskoro. Svi mogu pomoći ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr -- follow me - www.twitter.com/valentt http://kernelreloaded.blog385.com linux, anime, spirituality, wireless, scuba, linuxmce smart home, zwave ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turko...@hotmail.com -- follow me - www.twitter.com/valentt http://kernelreloaded.blog385.com linux, anime, spirituality, wireless, scuba, linuxmce smart home, zwave ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turko...@hotmail.com -- follow me - www.twitter.com/valentt http://kernelreloaded.blog385.com linux, anime, spirituality, wireless, scuba, linuxmce smart home, zwave ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turko...@hotmail.com ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Promotivni OSM letak
Evo png i Inkscape verzije: https://www.dropbox.com/s/b5vv06xmveq4uyc/OSM%20plakat.png https://www.dropbox.com/s/7e1sg0ur3kuldjk/OSM%20plakat.svg 2014-02-26 23:07 GMT+01:00 valent.turko...@gmail.com valent.turko...@gmail.com: Evo i verzija s logom: http://i.imgur.com/kaO8Cjs.png 2014-02-26 22:56 GMT+01:00 valent.turko...@gmail.com valent.turko...@gmail.com: Evo sitnih izmjena: http://i.imgur.com/70zBitX.png 2014-02-26 22:32 GMT+01:00 valent.turko...@gmail.com valent.turko...@gmail.com: Draft ideja za prednju stranicu: http://i.imgur.com/jWRj1Ic.png 2014-02-26 22:28 GMT+01:00 valent.turko...@gmail.com valent.turko...@gmail.com: Može. On 26 Feb 2014 17:29, hbogner hbog...@gmail.com wrote: On 02/26/2014 05:14 PM, valent.turko...@gmail.com wrote: Tekst je OK, no previše je teksta. Za letak bi trebalo biti više šareno a manje teksta. Npr. na naslovnici slika neka i samo kratko; mi kartiramo svijet pridruži nam se. A s druge strane tekst, ali kraći i link na wiki gdje mogu saznati više. Sa osm-hr.org imaju linkna wiki Jel ti se da složi svoju verziju? Mogu ti dati scribus fajl- preradu, nalazi se u dropboxu, a mogu ti dati i corel file ako jos postoji negdje. evo i nekog svg ekstrakta, neznam kako je to tocno kreirano :D https://dl.dropboxusercontent.com/u/3220458/letak_a6_v0.1-1.svg https://dl.dropboxusercontent.com/u/3220458/letak_a6_v0.1-2.svg evo i slika: https://dl.dropboxusercontent.com/u/3220458/qr-osm.png https://dl.dropboxusercontent.com/u/3220458/qr-osmhr.png https://dl.dropboxusercontent.com/u/3220458/200px-Logo_Croatia.svg.png https://dl.dropboxusercontent.com/u/3220458/Logo_Croatia.svg https://dl.dropboxusercontent.com/u/3220458/osm_logo.png Ja u ovom trenutku nestignem, a sutra bi to tiskao jer mi treba uskoro. Svi mogu pomoći ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr -- follow me - www.twitter.com/valentt http://kernelreloaded.blog385.com linux, anime, spirituality, wireless, scuba, linuxmce smart home, zwave ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turko...@hotmail.com -- follow me - www.twitter.com/valentt http://kernelreloaded.blog385.com linux, anime, spirituality, wireless, scuba, linuxmce smart home, zwave ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turko...@hotmail.com -- follow me - www.twitter.com/valentt http://kernelreloaded.blog385.com linux, anime, spirituality, wireless, scuba, linuxmce smart home, zwave ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turko...@hotmail.com -- follow me - www.twitter.com/valentt http://kernelreloaded.blog385.com linux, anime, spirituality, wireless, scuba, linuxmce smart home, zwave ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turko...@hotmail.com ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Promotivni OSM letak
Super, ali tu verziju u boji ćemo onda za sljedeću verziju. Za sutra trebam spremiti crno bijelu verziju. Nju možemo dijeliti po planinarskim domovima, biciklističkim klubovima i sličnim mjestima..., ali i radionicama, predavanjima, konferencijama, ... On 02/26/2014 11:07 PM, valent.turko...@gmail.com wrote: Evo i verzija s logom: http://i.imgur.com/kaO8Cjs.png ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Promotivni OSM letak
On 02/26/2014 11:16 PM, valent.turko...@gmail.com wrote: Evo png i Inkscape verzije: https://www.dropbox.com/s/b5vv06xmveq4uyc/OSM%20plakat.png https://www.dropbox.com/s/7e1sg0ur3kuldjk/OSM%20plakat.svg Kao što naziv kaže ovo je super za neki veći plakat :D Za A6 letak bi ipak stavio nešto više informacija. ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Promotivni OSM letak
Nope, za manji plakat ide i manje informacija, ako staviš hrpe teksta budi siguran da će sve završiti u košu. Informacije se daju usmeno ili na webu. Letak je tu samo da ih privuče. On 26 Feb 2014 23:20, hbogner hbog...@gmail.com wrote: On 02/26/2014 11:16 PM, valent.turko...@gmail.com wrote: Evo png i Inkscape verzije: https://www.dropbox.com/s/b5vv06xmveq4uyc/OSM%20plakat.png https://www.dropbox.com/s/7e1sg0ur3kuldjk/OSM%20plakat.svg Kao što naziv kaže ovo je super za neki veći plakat :D Za A6 letak bi ipak stavio nešto više informacija. ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr
Re: [OSM-talk-be] (geen onderwerp)
Oei, ik ben al een uur te laat. Ik kom toe over een half uur. Ik zit hier nog te spetteren in Wetteren. Jo Op 25 februari 2014 14:53 schreef Jorieke Vyncke jorieke.vyn...@gmail.com: Hallo allemaal, Morgen is het nog eens OpenStreetMap bijeenkomst in Gent! Dus iedereen is welkom om 19u in de Vooruit tussen pot en pint. http://www.meetup.com/OpenStreetMap-Belgium/events/166866572/ Ook als je nu niet kan komen, kan je je inschrijven in de meetup-groep. Dan wordt je automatisch op de hoogde gehouden van volgende osm activiteiten. Tot morgen, Jorieke ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
[OSM-talk-be] 1 or 2 lanes ?
I have a highway with separate roads in each direction. Each road has one lane for traffic and one breakdown lane to the right. Normally we tag this as a road with one one-way lane (we only count TRAFFIC lanes, see http://wiki.openstreetmap.org/wiki/Key:lanes). The highway goes through a tunnel. Each road has its own pipe in the tunnel. When entering the tunnel, the breakdown lane is now marked as a spare lane where traffic is not allowed (red X signal above the lane). The idea is to open the spare lane in case of accidents or in case the pipe in the other direction needs to be closed and the normal lane will be used for traffic in the opposite direction. How should this be tagged ? Change from lanes = 1 to lanes = 2 and back to one when we are at the end of the tunnel? Are there additional tags for such a situation ? Examples ? Gilbert ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-legal-talk] [Talk-ca] Nouvelle licence de données ouvertes au Québec
On Fri, Feb 21, 2014 at 3:12 AM, Diane Mercier diane.merc...@gmail.comwrote: I reiterate. It is the responsibility of OSM Foundation to instruct his community of his CC 4.0 interpretation as it has done for the CC 2.0 and CC 3.0 And in my humble opinion, the tiles and the BD licenses should updates to CC 4.0 to reduce proliferation of license, etc. Note that this is a substantially different task for 4.0 than for 3.0, because 4.0 (particularly BY-SA) now includes a database copyleft clause. Assessing how the ODBL and CC BY-SA 4.0 database clauses interact will be challenging. OSM/Open Data Commons could simplify the problem by declaring that CC 4.0 is a compatible license under ODBL 4.4(a)(iii), but there would still be some complexities to work through. Luis -- Luis Villa Deputy General Counsel Wikimedia Foundation 415.839.6885 ext. 6810 NOTICE: *This message may be confidential or legally privileged. If you have received it by accident, please delete it and let us know about the mistake. As an attorney for the Wikimedia Foundation, for legal/ethical reasons I cannot give legal advice to, or serve as a lawyer for, community members, volunteers, or staff members in their personal capacity.* ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] Not attaching polygons to roads
Clifford Snow wrote: When editing, it is time consuming to make changes to one when the two are connected. Leaving the two connect can lead to problems if the editor doesn't see that they inadvertently moved the other. Roads are not a special case here ... any way elements that co-exist with other polygon boundary ways can be equally problematic. Bundling relations into this adds another layer of problems which make them as difficult to manage as simple polygons. I have said this before, but it does really need to be looked at a lot closer ... What we need here is to add a 'polygon' which consists of a combination of ways in much the same way as 'nodes' get combined. This is essentially a relation rather than an area, but I will repeat the example I've given before. There is a substantial amount of micro mapping going on now, so for example a field or property polygon may well have one boundary as a road, two as fences and the fourth as a hedge. Since the way making up the polygon can't be used for the boundary elements one ends up having to trace them, creating multiple elements overlapping. Directly related to this thread, the next step may be to add 'say' the dry stone wall that in reality divides the field from the road! Pulling the boundary ways and polygon apart to add the extra detail is currently painful? If however the 'field' simply consisted of 4 closed ways, one could postulate that selecting the road element of the field/property would allow the option to 'parallel' but maintain the other boundary elements to remain with the separated field rather than having to be broken out individually. Going on from this editing operation ... the new way will probably have an access point which could not previously be mapped ON the road, but can now be identified as a link off the road. The remaining problems pulling this element apart from the originally linked components is perhaps 'landuse=agricultural' polygon which may well be overlaying the field polygon as well! Should the landuse polygon remain using the road way as it's boundary or should it switch to the separated field way boundary? That would be allowed by maintaining the landuse detail with one or other of the new separate ways. I see this as a stepping stone maintaining the integrity of the larger area polygons that are currently handled as 'relations' but are more accurately closed way polygons and the same new tools that would manage fine detail polygons could also be used to maintain the integrity of larger 'polygons' such as administrative boundaries or larger landuse areas that are currently created from a large number of conventional polygons? It is not unusual these days to find several ways all overlaying one another, and that can probably be simply extracted from the data? They are using the same nodes but often the real reason for the 'boundary' is not easily identified and adding that data currently requires an additional way for say 'fence', where simply adding that tag to a single multiply used way would be a lot more accurate? There will still be situations where a simple polygon is appropriate, such as perhaps dropping buildings within a property boundary, and 'semi-detached' properties would have a common element with the boundary polygon, and additional tools may be required to insert these fine details into the larger elements, but that simply ensures that the data integrity is maintained? Deleting or modifying elements that ARE being used by higher level areas should be easier to identify? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
On Wed, Feb 26, 2014 at 1:33 AM, Clifford Snow cliff...@snowandsnow.us wrote: 5m,10m... and there is no reason to virtualy extend them and falsify the real world. +1 omg. In the real world, a highway is not a thin polyline... Wouldn't it be nice if the editors wouldn't allow polygon to connect to highways. I understand that it hard to implement, but when you need to make changes to either object, it is a pain. Think that, in some parts of the world, you don't have high res. images and you cannot count the amout of lanes or see the shoulders or the limit between the road and next landuse. Or that the person adding landuse is working at a municipality level, not at a fence level. It was always like this in OSM, the first contributor adds a node for a townhall, the second draws or import the building footprint and move the tags from the node to the way, etc. The crowd is not mapping at the same map scale. Assuming you start to map fences and walls, you have to adapt the existing data to your level of contributions. But you shouldn't forbid other contributions if they are not at your expectations. Again, it's an iterative concept. New contributions increase the quality. What is not acceptable is that new contributions decrease the level of the mapping (excepted in some cases I could develop) Pieren ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] SOTM-EU talk submission extended
Hello everyone, the Call for Presentations for the SOTM EU conference taking place in Karlsruhe in June is extended until March 17. We have already received a lot of interesting talks and would like to give everyone who is preparing a submission a bit more time. Also if you have not yet planned to submit something or maybe have missed the previous announcements now is your chance. We specifically want to invite OSM contributors from all over Europe (and beyond) to participate and submit their topics. Talks can be submitted on the conference website: http://sotm-eu.org/en/presentations/new where you can also find further information on the event. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
On 26/02/2014 01:02, Mike Thompson wrote: Wouldn't it be nice if the editors wouldn't allow polygon to connect to highways. The edges of some polygons are truly coincident with road centerlines. For example, many municipal boundaries. I'm not convinced this is usually true. It maybe UK specific, but municipal boundaries were more likely to originally be placed on physical boundaries to farms estates such as walls, fences etc. before tracks/roads were developed. Roads subsequently evolved along those boundaries afterwards. It would be pretty silly to have a municiple boundary splitting the centre of a road so different administrations were responsible for maintaining the left the right. Dave F. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
Inthe UK the boundaries were there long before road maintenance was thought of. A couple of real life examples http://osm.org/go/eu5Dsjb0--?layers =N The border between Leicestershire and Warwickshire has been split to either side of Watling Street to solve the problem of maintenance. The boundary original used the Roman road to define the border between The Danelaw and Saxon Mercia. http://osm.org/go/euehosUf--?layers=N The English Welsh border runs along the centre of the main street. I assume shropshire and powis have an arrangement. Phil (trigpoint) -- Sent from my Nokia N9 On 26/02/2014 10:42 Dave F. wrote: On 26/02/2014 01:02, Mike Thompson wrote: Wouldn't it be nice if the editors wouldn't allow polygon to connect to highways. The edges of some polygons are truly coincident with road centerlines. For example, many municipal boundaries. I'm not convinced this is usually true. It maybe UK specific, but municipal boundaries were more likely to originally be placed on physical boundaries to farms estates such as walls, fences etc. before tracks/roads were developed. Roads subsequently evolved along those boundaries afterwards. It would be pretty silly to have a municiple boundary splitting the centre of a road so different administrations were responsible for maintaining the left the right. Dave F. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ talk mailing list talk@openstreetmap.org http://www.avast.com ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
On 26/02/2014 10:27, Pieren wrote: On Wed, Feb 26, 2014 at 1:33 AM, Clifford Snow cliff...@snowandsnow.us wrote: 5m,10m... and there is no reason to virtualy extend them and falsify the real world. +1 omg. In the real world, a highway is not a thin polyline... Yes, that why he's saying don't attach it to the centreline in the belief it's the edge. Wouldn't it be nice if the editors wouldn't allow polygon to connect to highways. I understand that it hard to implement, but when you need to make changes to either object, it is a pain. Think that, in some parts of the world, you don't have high res. images and you cannot count the amout of lanes or see the shoulders or the limit between the road and next landuse. If there's no imagery to work from the person has never seen the area before then they really shouldn't be mapping it. If a visual survey has been performed a bit of 'guesstimating' the distance to the centreline from the boundary edge is *still* more accurate than attaching it the the way of the road. Or that the person adding landuse is working at a municipality level, not at a fence level. It was always like this in OSM, the first contributor adds a node for a townhall, the second draws or import the building footprint and move the tags from the node to the way, etc. The crowd is not mapping at the same map scale. Assuming you start to map fences and walls, you have to adapt the existing data to your level of contributions. Agree But you shouldn't forbid other contributions if they are not at your expectations. Not sure how you 'forbid' data, but if the contributions are to existing data reduce the information or accuracy, then they should be reverted. Again, it's an iterative concept. New contributions increase the quality. What is not acceptable is that new contributions decrease the level of the mapping (excepted in some cases I could develop) Unfortunately, that's what's happened in my case. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
On 2014-02-26 11:42, Dave F. wrote: On 26/02/2014 01:02, Mike Thompson wrote: Wouldn't it be nice if the editors wouldn't allow polygon to connect to highways. The edges of some polygons are truly coincident with road centerlines. For example, many municipal boundaries. I'm not convinced this is usually true. It maybe UK specific, but municipal boundaries were more likely to originally be placed on physical boundaries to farms estates such as walls, fences etc. before tracks/roads were developed. Roads subsequently evolved along those boundaries afterwards. It would be pretty silly to have a municiple boundary splitting the centre of a road so different administrations were responsible for maintaining the left the right. Like here [1]. The border is in the middle of the road, the roadlayout and signage is Dutch, but the sign on the building to the left is German (and is on German ground). But the same is true for border rivers. Then there also has to be agreement in procedures. [1] https://maps.google.nl/?ll=50.860225,6.077156spn=0.006014,0.032873t=mz=15layer=ccbll=50.860226,6.077161panoid=SQRceC4dd39DbQRqRCy1zgcbp=11,195.8,,0,3.32 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
On 26/02/2014 11:16, Maarten Deen wrote: On 2014-02-26 11:42, Dave F. wrote: I'm not convinced this is usually true. It maybe UK specific, but municipal boundaries were more likely to originally be placed on physical boundaries to farms estates such as walls, fences etc. before tracks/roads were developed. Roads subsequently evolved along those boundaries afterwards. It would be pretty silly to have a municiple boundary splitting the centre of a road so different administrations were responsible for maintaining the left the right. Like here [1]. The border is in the middle of the road, Actually in the /middle/ of the road? I see no evidence of that. I'm not suggesting Google Maps are definitive, but they show it to one side. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
On 2014-02-26 12:31, Dave F. wrote: On 26/02/2014 11:16, Maarten Deen wrote: On 2014-02-26 11:42, Dave F. wrote: I'm not convinced this is usually true. It maybe UK specific, but municipal boundaries were more likely to originally be placed on physical boundaries to farms estates such as walls, fences etc. before tracks/roads were developed. Roads subsequently evolved along those boundaries afterwards. It would be pretty silly to have a municiple boundary splitting the centre of a road so different administrations were responsible for maintaining the left the right. Like here [1]. The border is in the middle of the road, Actually in the /middle/ of the road? I see no evidence of that. I'm not suggesting Google Maps are definitive, but they show it to one side. Yes. In the middle of the road. See [1], In het midden van de rotonde stond gp230, translated: in the middle of the roundabout was gp230 located. The roundabout on the photo is located a bit more to the south where there is not streetview. That part was actually physically separated with a stone ridge, see the next photo. Now it is a joint road. GP231 is located when you take my SV link, turn around and go to the next roundabout. [1] http://www.grenspalen.nl/archief-denl/gp-depruis-nl-228-238.html Maarten ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
On Wed, Feb 26, 2014 at 6:42 PM, Dave F. dave...@madasafish.com wrote: I'm not convinced this is usually true. It maybe UK specific, but municipal boundaries were more likely to originally be placed on physical boundaries to farms estates such as walls, fences etc. before tracks/roads were developed. Roads subsequently evolved along those boundaries afterwards. It would be pretty silly to have a municiple boundary splitting the centre of a road so different administrations were responsible for maintaining the left the right. This is usually true in my country. For example, here's the legal definition of a district in the capital Manila: Malate. - Beginning at the intersection of west face of the sea wall on Dewey Boulevard and the center line of Calle Cuarteles; thence along the center line of Calle Cuarteles, M. H. del Pilar and Herran, and Esteros de Paco, and Tripa de Gallina, to the city boundary line; thence westerly along said boundary line to high-water line on Manila Bay; and thence northerly along said high-water line and the west face of said sea wall to the point of beginning.[1] Hence, the relation for the Malate district[2] contains rivers and roads (and coastlines) as members. [1] http://philippinelaw.info/statutes/ra409-revised-charter-of-the-city-of-manila.html [2] http://www.openstreetmap.org/relation/103704 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
On 02/26/2014 12:11 PM, Dave F. wrote: On 26/02/2014 10:27, Pieren wrote: On Wed, Feb 26, 2014 at 1:33 AM, Clifford Snow cliff...@snowandsnow.us wrote: 5m,10m... and there is no reason to virtualy extend them and falsify the real world. +1 omg. In the real world, a highway is not a thin polyline... Yes, that why he's saying don't attach it to the centreline in the belief it's the edge. Yes, that's what I'm saying. Don't attach landuse and other real world representing polygons to the road centerline. We should not attach landuse=park,grass,cemetary,... to highway=road,primary,secundary, ... Administrative borders are completely another case, they are MOSTLY imaginary lines that divide world to political regions... ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
2014-02-26 14:50 GMT+01:00 hbogner hbog...@gmail.com: Yes, that's what I'm saying. Don't attach landuse and other real world representing polygons to the road centerline. We should not attach landuse=park,grass,cemetary,... to highway=road,primary,secundary, ... I am going even further by saying ideally a landuse=residential/industrial/commercial/retail polygon should not incorporate any public road at all. I agree that this way of mapping means significantly more work initially, but it leads to better (less forgotten / overlooked different landuses) and more detailed data afterwards and it is much easier to edit and more clear what is going on. Atomic mapping (smaller patches instead of huge polygons) also leads to fewer version numbers and to a clearer history, and to faster rendering/processing times for high zoom levels (you only have to look at the actually interesting data and not the data out of sight but in the same polygon). a wider acceptance / mapping of landuse=highway for the legal highway (or in other words, the gap between the above mentioned landuses in built-up areas) would sure help getting this done earlier. cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
On 26/02/2014 15:35, Martin Koppenhoefer wrote: I am going even further by saying ideally a landuse=residential/industrial/commercial/retail polygon should not incorporate any public road at all. But then how do you tag named industrial or commercial zones ? In France there are ZI Zone Industrielle or ZA 'Zone d'Activité) which include public ways. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
On 26/02/2014, Dave F. dave...@madasafish.com wrote: On 26/02/2014 11:16, Maarten Deen wrote: On 2014-02-26 11:42, Dave F. wrote: It would be pretty silly to have a municiple boundary splitting the centre of a road so different administrations were responsible for maintaining the left the right. Like here [1]. The border is in the middle of the road, Actually in the /middle/ of the road? I see no evidence of that. I'm not suggesting Google Maps are definitive, but they show it to one side. I don't have a link to share, but there is such a road in my hometown in France. It caused no end of grief from the residents, because either both municipalities would decide to do no road improvement at all, or they'd work on only half the road. If you thought municipalities and road administrations never do silly things, think again. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
On 26/02/2014, Dave F. dave...@madasafish.com wrote: On 26/02/2014 10:27, Pieren wrote: On Wed, Feb 26, 2014 at 1:33 AM, Clifford Snow cliff...@snowandsnow.us Think that, in some parts of the world, you don't have high res. images and you cannot count the amout of lanes or see the shoulders or the limit between the road and next landuse. If there's no imagery to work from the person has never seen the area before then they really shouldn't be mapping it. If a visual survey has been performed a bit of 'guesstimating' the distance to the centreline from the boundary edge is *still* more accurate than attaching it the the way of the road. That guesstimate is often way off when you have no imagery and little data, because your sense of scale has no reference. I've made the mistake many times only to think silly me when revisiting an area once imagery became available. In that context, I agree that glueing the poly to the street may be just as good as separating it. At least then it's obvious that the data is just a schematic model and not an accurate-ish representation. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
Jean-Marc Liotier jm at liotier.org writes: On 26/02/2014 15:35, Martin Koppenhoefer wrote: I am going even further by saying ideally a landuse=residential/industrial/ commercial/retail polygon should not incorporate any public road at all. But then how do you tag named industrial or commercial zones ? In France there are ZI Zone Industrielle or ZA 'Zone d'Activité) which include public ways. Use multipolygons. -- Andrew ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
On 26/02/2014 18:34, moltonel 3x Combo wrote: On 26/02/2014, Dave F. dave...@madasafish.com wrote: On 26/02/2014 10:27, Pieren wrote: On Wed, Feb 26, 2014 at 1:33 AM, Clifford Snow cliff...@snowandsnow.us Think that, in some parts of the world, you don't have high res. images and you cannot count the amout of lanes or see the shoulders or the limit between the road and next landuse. If there's no imagery to work from the person has never seen the area before then they really shouldn't be mapping it. If a visual survey has been performed a bit of 'guesstimating' the distance to the centreline from the boundary edge is *still* more accurate than attaching it the the way of the road. That guesstimate is often way off when you have no imagery and little data, because your sense of scale has no reference. I've made the mistake many times only to think silly me when revisiting an area once imagery became available. In that context, I agree that glueing the poly to the street may be just as good as separating it. At least then it's obvious that the data is just a schematic model and not an accurate-ish representation. As I see it, a separate poly would be inaccurate, a joined poly to way would be wrong, so ironically the inaccurate would be the more accurate. Dave F. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
On 26/02/2014 18:42, moltonel 3x Combo wrote: On 26/02/2014, Dave F. dave...@madasafish.com wrote: On 26/02/2014 11:16, Maarten Deen wrote: On 2014-02-26 11:42, Dave F. wrote: It would be pretty silly to have a municiple boundary splitting the centre of a road so different administrations were responsible for maintaining the left the right. Like here [1]. The border is in the middle of the road, Actually in the /middle/ of the road? I see no evidence of that. I'm not suggesting Google Maps are definitive, but they show it to one side. I don't have a link to share, but there is such a road in my hometown in France. It caused no end of grief from the residents, because either both municipalities would decide to do no road improvement at all, or they'd work on only half the road. If you thought municipalities and road administrations never do silly things, think again. I stand corrected. There are silly people. Thanks for all you examples. Dave F. --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
2014-02-26 15:56 GMT+01:00 Jean-Marc Liotier j...@liotier.org: But then how do you tag named industrial or commercial zones ? In France there are ZI Zone Industrielle or ZA 'Zone d'Activité) which include public ways. I would do this with name and place tags. cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
2014-02-26 19:43 GMT+01:00 Andrew Hain andrewhain...@hotmail.co.uk: Jean-Marc Liotier jm at liotier.org writes: On 26/02/2014 15:35, Martin Koppenhoefer wrote: I am going even further by saying ideally a landuse=residential/industrial/ commercial/retail polygon should not incorporate any public road at all. But then how do you tag named industrial or commercial zones ? In France there are ZI Zone Industrielle or ZA 'Zone d'Activité) which include public ways. Use multipolygons. I wouldn't do this because here you would need the roads to be part of the zone (as well as other landuses that are inside this zone). cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-br] Mapas do IBGE
Ola,
No ano passado, abaixei alguns mapas do IBGE e fiz um processamento
segundo as etapas abaixo. O resultado nao e perfeito, mais...
A etapa #5 e a mais trablahosa e tem 30+ setores censitarios no
minicipio :-(
Abs, Hermann
-
# 0. Create a working directory and use it
mkdir mapas_de_setores_censitarios
cd mapas_de_setores_censitarios
# 1. Download IBGE maps for Ivoti, RS
wget
ftp://geoftp.ibge.gov.br/mapas_estatisticos/censo_2010/mapas_de_setores_censitarios/RS/4310801.zip
# 2. Extract all relevant maps (there are 34 sectors in Ivoti)
unzip -j 4310801.zip */4310801.pdf
# 3. Convert maps to PNG, in reasonable resolution (200 dpi)
for f in *.pdf ; do convert -density 200 $f ${f%pdf}png ; done
# 4. Georeference 43108010501.png, through visual inspection :-(
# Upper left corner of the actual map at pixel 164,121
-51d09'51 = -51.164167 longitude
-29d35'20 = -29.59 latitude
# Lower right corner of the actual map at pixel 2226,2838
-51d09'23 = -51.156389 longitude
-29d35'57 = -29.599167 latitide
# 5. Apply the above values as ground control points (GCPs)
# Assuming that the undocumented datum is SIRGAS2000 = EPSG:4674
gdal_translate 43108010501.png 43108010501.tif \
-gcp 164 121 -51.164167 -29.59 \
-gcp 2226 2838 -51.156389 -29.599167 \
-gcp 2226 121 -51.156389 -29.59 \
-a_srs epsg:4674
# 6. JOSM/PicLayer only supports PNG, JPEG or GIF formats
# only EPSG:3857 is supported, world files are understood
# Warp the file to EPSG:3857 = WGS 84 / Pseudo-Mercator
gdalwarp 43108010501.tif 43108010501_epsg3857.tif \
-t_srs epsg:3857 -co tfw=yes
# Change image format, rename world file
convert 43108010501_epsg3857.tif 43108010501_epsg3857.jpg
mv 43108010501_epsg3857.tfw 43108010501_epsg3857.wld
On 2014-02-25 19:29, Fernando Trebien wrote:
Como era o seu antigo método? Não temos preconceitos. :D
On Feb 25, 2014 1:57 PM, Raffaello Bruno Limongi Freire
raffaellobruno-pkbjnfxxiarbdgjk7y7...@public.gmane.org
mailto:raffaellobruno-pkbjnfxxiarbdgjk7y7...@public.gmane.org wrote:
Arlindo/Vitor,
consegui visualizar e georreferenciar um mapa do IBGE no JOSM, mas
deu tando trabalho que eu não sei se será mais eficiente do que meu
antigo método tabajara... :)
Uma vantagem que eu vejo é que só precisa calibrar uma vez para
visualizar quantas vezes quiser.
Obrigado.
From:
openstreetmap-qpc2wcgjr8vppgbeqg0jjtbpr1lh4...@public.gmane.org
mailto:openstreet...@arlindopereira.com
Date: Mon, 24 Feb 2014 20:37:28 -0300
To: talk-br-3+rWM/WnaLOn4i5uJCXUsti2O/jbr...@public.gmane.org
mailto:talk-br@openstreetmap.org
Subject: Re: [Talk-br] Mapas do IBGE
O Vitor foi mais rápido que eu. :-P
Discutimos isso ano passado:
https://lists.openstreetmap.org/pipermail/talk-br/2013-January/003109.html
2014-02-24 20:27 GMT-03:00 Vítor Rodrigo Dias
vitor.dias-re5jqeeqqe8avxtiumw...@public.gmane.org
mailto:vitor.dias-re5jqeeqqe8avxtiumw...@public.gmane.org:
Raffaello,
O ideal é converter os PDFs para imagem e usar o PicLayer para
colocá-los como imagens de fundo. Uma outra dica é, no PicLayer,
alinhar os limites dos PDFs usando o KML do IBGE com os limites
de setores censitários.
Abraços,
Vítor Dias
Em 24/02/2014 20:20, Raffaello Bruno Limongi Freire
raffaellobr...@hotmail.com
mailto:raffaellobruno-pkbjnfxxiarbdgjk7y7...@public.gmane.org
escreveu:
Oi, Arlindo,
não sei se vou ser claro, mas minha dúvida é como visualizar
esses mapas do IBGE como uma camada adicional no editor, ou
seja, como visualizar os dados do IBGE e do OSM em uma mesma
janela, _caso possível_, para facilitar o mapeamento.
O procedimento artesanal que faço para o Tracksouce, e que
eu queria otimizar no OSM, é abrir os PDFs do IBGE e os
mapas em janelas separadas para ficar comparando, o que não
é muito produtivo.
Para ficar mais claro, por exemplo, abro um mapa do IBGE e
visualizo um cruzamento entre a Rua X e a Rua Y. Aí, eu abro
o mapa do Tracksource (em outro aplicativo) e tento
localizar esse cruzamento. Feito isso, saio comparando as
informações nessa região para ver se não há mais alguma
informação que eu possa adicionar, como nomes de ruas faltantes.
O problema, é que esses arquivos de mapas, em formato PDF,
são muito fragmentados, e dá muito trabalho ficar abrindo um
por um em janelas distintas das janelas do editor.
Obrigado.
Raffaello Bruno
From:
[Talk-br] Restrições de conversão usando linha como intermediário
Pessoal, Repensando um pouco sobre este tutorial (http://wiki.openstreetmap.org/wiki/Pt-br:Tutorial:Restri%C3%A7%C3%B5es_de_Convers%C3%A3o#Linha_como_intermedi.C3.A1rio), fico na dúvida do que exatamente recomendar pros iniciantes. O problema é que restrições que usam linhas com o papel via (ao invés de só um ponto) não são suportadas em nenhuma aplicação. Mapear desta forma faria o roteamento dar errado em todas as aplicações que existem hoje. Eu relatei essa situação no final dessa seção. O que eu recomendei foi usar um ponto intermediário e circular o cruzamento com uma linha com fixme, mas eu me pergunto se não seria menos pior inventar conexões (como descreve a seção seguinte) e colocar um fixme nelas mesmas. Contras de usar um ponto: - instruções ligeiramente erradas no navegador - aspecto visual estranho Prós de usar conexões virtuais: - instruções corretas - aspecto visual quase correto (depende de como a linha é desenhada) Contras: - infringe a semântica da separação das vias Opiniões? -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Restrições de conversão usando linha como intermediário
2014-02-26 15:24 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Opiniões? Eu pessoalmente prefiro manter a geometria correta da rodovia, mesmo que acabe ficando com uma restrição não-funcional. O que dá para fazer em alguns casos é substituir por uma restrição equivalente. Por exemplo, locais com proibido retornar + proibido virar à esquerda podem ser representados apenas com um proibido virar à esquerda (usando um nó como via). ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Restrições de conversão usando linha como intermediário
Ontem que comecei a criar restrições, nunca tinha criado uma antes. No TrackSource não precisavamos quebrar uma via para fazer uma restrição nela, apenas ligavamos os pontos onde nao se podia. Quando fui fazer pelo josm, o plugin de restrições disse que eu tinha que quebrar e já até apresentava um botão pra automatizar isso. Então no JOSM sempre vai ser assim, não dá pra fazer por nós? Em 26 de fevereiro de 2014 15:45, Nelson A. de Oliveira nao...@gmail.comescreveu: 2014-02-26 15:24 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Opiniões? Eu pessoalmente prefiro manter a geometria correta da rodovia, mesmo que acabe ficando com uma restrição não-funcional. O que dá para fazer em alguns casos é substituir por uma restrição equivalente. Por exemplo, locais com proibido retornar + proibido virar à esquerda podem ser representados apenas com um proibido virar à esquerda (usando um nó como via). ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Restrições de conversão usando linha como intermediário
Segundo o que eu entendi restrições de manobra são relações apenas entre vias, por isso você tem que quebrá-las. Mas acho interessante propor a mudança da relação para nós e não vias. Em 26 de fevereiro de 2014 15:48, Erick de Oliveira Leal erickdeoliveiral...@gmail.com escreveu: Ontem que comecei a criar restrições, nunca tinha criado uma antes. No TrackSource não precisavamos quebrar uma via para fazer uma restrição nela, apenas ligavamos os pontos onde nao se podia. Quando fui fazer pelo josm, o plugin de restrições disse que eu tinha que quebrar e já até apresentava um botão pra automatizar isso. Então no JOSM sempre vai ser assim, não dá pra fazer por nós? Em 26 de fevereiro de 2014 15:45, Nelson A. de Oliveira nao...@gmail.comescreveu: 2014-02-26 15:24 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Opiniões? Eu pessoalmente prefiro manter a geometria correta da rodovia, mesmo que acabe ficando com uma restrição não-funcional. O que dá para fazer em alguns casos é substituir por uma restrição equivalente. Por exemplo, locais com proibido retornar + proibido virar à esquerda podem ser representados apenas com um proibido virar à esquerda (usando um nó como via). ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Plugin confaltion do JOSM
Srs, Desculpem a demora em responder, estava enrolado em achar o Java 6 para instalação. Pois bem. Instalei o Ubuntu do zero, com o java 6. Usei os JOSMs 6502, 6409 e 6296 Sempre com o mesmo erro, consigo até listar os erros encontrados nos mapas, mas na hora de conflacionar, erro!!! Aliás, na versão 6296 o conflation nem carregou, deu pau na inicialização. Se alguem tiver uma combinação JOSM + JAVA funcional, por favor me avise. Ou outra ferramenta que faça a mesma coisa. Agradeço às dicas recebidas, Att, Marcelo Pereira Em 24 de fevereiro de 2014 19:13, Paulo Carvalho paulo.r.m.carva...@gmail.com escreveu: Pode ser mesmo biblioteca incompatível. Agora qual eu não sei. Estou sem condição de investigar isso. Estou com coisas mais fundamentais para investigar como a compilação com mkgmap. Em 24 de fevereiro de 2014 16:31, Fernando Trebien fernando.treb...@gmail.com escreveu: Esses erros de introspecção já foram relatados no bug tracker do plugin, mas o desenvolvedor parece ter meio que abandonado o projeto, ou pelo menos não o estar priorizando (afinal, se funciona com Java 6...). Lembro vagamente de ter lido algum stack trace que sugeria que o erro acontece numa das bibliotecas de que o plugin depende, uma das usadas para calcular a semelhança topológica entre as duas malhas. 2014-02-22 15:22 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Faz sentido usar JOSMs mais antigos. O erro postado pelo Marcelo parece ser um erro de introspecção (erro de funcionamento interno). A grosso modo o plugin não está falando a mesma língua do framework (JOSM). O desenvolvedor do plugin de conflação deve dar uma olhada nas APIs novas e removidas do JOSM. Em 22 de fevereiro de 2014 12:40, Erick de Oliveira Leal erickdeoliveiral...@gmail.com escreveu: Marcelo, vai testando com esses JOSMs mais antigos: http://josm.openstreetmap.de/download/Archiv/ Vai tentando com intervalos de 2 em 2 meses pra ser mais rapido Em 22 de fevereiro de 2014 12:35, Marcelo Pereira pereirahol...@gmail.com escreveu: Erick, Obrigado pela ajuda, segue o erro apresentado ERROR: java.lang.NoSuchMethodError: org.openstreetmap.josm.command.AddPrimitivesCommand.init(Ljava/util/List;Lorg/openstreetmap/josm/gui/layer/OsmDataLayer;)V java.lang.NoSuchMethodError: org.openstreetmap.josm.command.AddPrimitivesCommand.init(Ljava/util/List;Lorg/openstreetmap/josm/gui/layer/OsmDataLayer;)V at org.openstreetmap.josm.plugins.conflation.ConflateMatchCommand.init(ConflateMatchCommand.java:42) at org.openstreetmap.josm.plugins.conflation.ConflationToggleDialog$ConflateAction.conflateMatchActionPerformed(ConflationToggleDialog.java:570) at org.openstreetmap.josm.plugins.conflation.ConflationToggleDialog$ConflateAction.actionPerformed(ConflationToggleDialog.java:547) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2018) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2341) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:252) at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:289) at java.awt.Component.processMouseEvent(Component.java:6505) at javax.swing.JComponent.processMouseEvent(JComponent.java:3320) at java.awt.Component.processEvent(Component.java:6270) at java.awt.Container.processEvent(Container.java:2229) at java.awt.Component.dispatchEventImpl(Component.java:4861) at java.awt.Container.dispatchEventImpl(Container.java:2287) at java.awt.Component.dispatchEvent(Component.java:4687) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4832) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4492) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4422) at java.awt.Container.dispatchEventImpl(Container.java:2273) at java.awt.Window.dispatchEventImpl(Window.java:2719) at java.awt.Component.dispatchEvent(Component.java:4687) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:735) at java.awt.EventQueue.access$200(EventQueue.java:103) at java.awt.EventQueue$3.run(EventQueue.java:694) at java.awt.EventQueue$3.run(EventQueue.java:692) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:87) at java.awt.EventQueue$4.run(EventQueue.java:708) at java.awt.EventQueue$4.run(EventQueue.java:706) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76) at
Re: [Talk-br] Restrições de conversão usando linha como intermediário
Eu também prefiro, e recomendei a mesma coisa (com uma justificativa) aqui: http://wiki.openstreetmap.org/wiki/Pt-br:Tutorial:Restri%C3%A7%C3%B5es_de_Convers%C3%A3o#Alternativas_equivalentes 2014-02-26 16:56 GMT-03:00 Gerald Weber gwebe...@gmail.com: Eu pessoalmente prefiro manter a geometria correta da rodovia, mesmo que acabe ficando com uma restrição não-funcional. O que dá para fazer em alguns casos é substituir por uma restrição equivalente. Por exemplo, locais com proibido retornar + proibido virar à esquerda podem ser representados apenas com um proibido virar à esquerda (usando um nó como via). Às vezes eu prefiro colocar um obrigatório seguir em frente no lugar de um proibido virar à esquerda. Não acompanhei a discussão toda, mas talvez isto seja de ajuda. abraço Gerald ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Restrições de conversão usando linha como intermediário
Ligavam os pontos? Interessante. Como funcionava isso, exatamente? A resposta é: sim, você sempre precisa quebrar. É preciso que as vias de entrada e saída sejam pedaços conectados, e que cada pedaço tenha como ponto extremo (ponto final): - o ponto intermediário (da interseção); ou - o início e o fim das vias intermediárias Depois dá uma lida nessas duas seções: - http://wiki.openstreetmap.org/wiki/Pt-br:Tutorial:Restri%C3%A7%C3%B5es_de_Convers%C3%A3o#Cria.C3.A7.C3.A3o - http://wiki.openstreetmap.org/wiki/Pt-br:Tutorial:Restri%C3%A7%C3%B5es_de_Convers%C3%A3o#Linha_como_intermedi.C3.A1rio E se tiver dúvidas já me avisa pra eu tentar tornar o tutorial mais claro e fácil de digerir. 2014-02-26 15:48 GMT-03:00 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: Ontem que comecei a criar restrições, nunca tinha criado uma antes. No TrackSource não precisavamos quebrar uma via para fazer uma restrição nela, apenas ligavamos os pontos onde nao se podia. Quando fui fazer pelo josm, o plugin de restrições disse que eu tinha que quebrar e já até apresentava um botão pra automatizar isso. Então no JOSM sempre vai ser assim, não dá pra fazer por nós? Em 26 de fevereiro de 2014 15:45, Nelson A. de Oliveira nao...@gmail.com escreveu: 2014-02-26 15:24 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Opiniões? Eu pessoalmente prefiro manter a geometria correta da rodovia, mesmo que acabe ficando com uma restrição não-funcional. O que dá para fazer em alguns casos é substituir por uma restrição equivalente. Por exemplo, locais com proibido retornar + proibido virar à esquerda podem ser representados apenas com um proibido virar à esquerda (usando um nó como via). ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Restrições de conversão usando linha como intermediário
O Paulo Carvalho sabe melhor pois ajudou a desenvolver as ferramentas. Eu só as usava. Em 26/02/2014 17:25, Fernando Trebien fernando.treb...@gmail.com escreveu: Ligavam os pontos? Interessante. Como funcionava isso, exatamente? A resposta é: sim, você sempre precisa quebrar. É preciso que as vias de entrada e saída sejam pedaços conectados, e que cada pedaço tenha como ponto extremo (ponto final): - o ponto intermediário (da interseção); ou - o início e o fim das vias intermediárias Depois dá uma lida nessas duas seções: - http://wiki.openstreetmap.org/wiki/Pt-br:Tutorial:Restri%C3%A7%C3%B5es_de_Convers%C3%A3o#Cria.C3.A7.C3.A3o - http://wiki.openstreetmap.org/wiki/Pt-br:Tutorial:Restri%C3%A7%C3%B5es_de_Convers%C3%A3o#Linha_como_intermedi.C3.A1rio E se tiver dúvidas já me avisa pra eu tentar tornar o tutorial mais claro e fácil de digerir. 2014-02-26 15:48 GMT-03:00 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: Ontem que comecei a criar restrições, nunca tinha criado uma antes. No TrackSource não precisavamos quebrar uma via para fazer uma restrição nela, apenas ligavamos os pontos onde nao se podia. Quando fui fazer pelo josm, o plugin de restrições disse que eu tinha que quebrar e já até apresentava um botão pra automatizar isso. Então no JOSM sempre vai ser assim, não dá pra fazer por nós? Em 26 de fevereiro de 2014 15:45, Nelson A. de Oliveira nao...@gmail.com escreveu: 2014-02-26 15:24 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com : Opiniões? Eu pessoalmente prefiro manter a geometria correta da rodovia, mesmo que acabe ficando com uma restrição não-funcional. O que dá para fazer em alguns casos é substituir por uma restrição equivalente. Por exemplo, locais com proibido retornar + proibido virar à esquerda podem ser representados apenas com um proibido virar à esquerda (usando um nó como via). ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Restrições de conversão usando linha como intermediário
Hm preciso fazer um exemplo disso. Mas acho que se você mudar a via intermediária por 1 nó só e proibir somente a conversão à esquerda, você acaba permitindo o retorno, não? Esse negócio de juntar num nó só geralmente é o que eu faço quando você pode virar à esquerda e não retornar, ou pode retornar mas não virar à esquerda. Mas eu acho (acho) que entendi a sua idéia, e concordo em tentar não alterar a geometria da via demais. Então, você estaria mais a favor das ligações inventadas se elas não alterarem muito a geometria, certo? 2014-02-26 15:45 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com: 2014-02-26 15:24 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Opiniões? Eu pessoalmente prefiro manter a geometria correta da rodovia, mesmo que acabe ficando com uma restrição não-funcional. O que dá para fazer em alguns casos é substituir por uma restrição equivalente. Por exemplo, locais com proibido retornar + proibido virar à esquerda podem ser representados apenas com um proibido virar à esquerda (usando um nó como via). ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Restrições de conversão usando linha como intermediário
O problema de usar um siga em frente ao invés de um proibido virar é que dá mais margem para gerar erros. Usando esse exemplo: http://i.imgur.com/j6VKrIp.png É proibido virar à esquerda (em vermelho), mas caso a pessoa utilize um siga em frente (em verde) e esse caminho de destino for muito grande, posteriormente alguém acaba alterando/quebrando/mesclando esse caminho (e de alguma forma quebrando a relação de restrição). Utilizando apenas o pequeno trecho que interliga as duas vias para criar uma restrição de proibido acaba dando menos margem para possíveis erros posteriores. Outro porém de usar um siga em frente é que a aplicação pode renderizar a placa de forma não muito correta (na rua vai ter uma placa dizendo proibido virar enquanto que a aplicação vai desenhar siga em frente; é algo mínimo que na prática gera o mesmo resultado, mas gera uma diferença de indicação) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Restrições de conversão usando linha como intermediário
2014-02-26 17:29 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Hm preciso fazer um exemplo disso. Mas acho que se você mudar a via intermediária por 1 nó só e proibir somente a conversão à esquerda, você acaba permitindo o retorno, não? Não em alguns casos. Exemplo: http://i.imgur.com/uiRNLqd.png Ao invés de fazer um proibido conversão com from A, via B, to C, pode-se fazer um proibido virar com from A, via n, to B. Essa proibição já impede de entrar no trecho B e portanto não vai dar para fazer um retorno para C. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Restrições de conversão usando linha como intermediário
posteriormente alguém acaba alterando/quebrando/mesclando esse caminho Alguém que usa o Potlatch né, porque tanto o iD quanto o JOSM tratam corretamente dessa situação. Mas concordo (até que consertem o Potlatch). Outro porém de usar um siga em frente é que a aplicação pode renderizar a placa de forma não muito correta Concordo. Mas existe uma aplicação amplamente usada que mostra as restrições? Se não existir, ou se servir só pra controle de qualidade no OSM, talvez isso não seja muito importante. Eu na verdade acho que só deveriam existir relações do tipo no_, isso eliminaria quase todas essas confusões. As only_ são um subconjunto (você pode expressá-las usando uma mais do tipo no_). Só que as only_ são as mais comuns na Alemanha (pelo jeito com que eles organizam o tráfego), e como quem desenvolve o JOSM é a comunidade alemã e a comunidade alemã é uma das mais participativas no OSM... difícil voltarem atrás. 2014-02-26 17:34 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com: O problema de usar um siga em frente ao invés de um proibido virar é que dá mais margem para gerar erros. Usando esse exemplo: http://i.imgur.com/j6VKrIp.png É proibido virar à esquerda (em vermelho), mas caso a pessoa utilize um siga em frente (em verde) e esse caminho de destino for muito grande, posteriormente alguém acaba alterando/quebrando/mesclando esse caminho (e de alguma forma quebrando a relação de restrição). Utilizando apenas o pequeno trecho que interliga as duas vias para criar uma restrição de proibido acaba dando menos margem para possíveis erros posteriores. Outro porém de usar um siga em frente é que a aplicação pode renderizar a placa de forma não muito correta (na rua vai ter uma placa dizendo proibido virar enquanto que a aplicação vai desenhar siga em frente; é algo mínimo que na prática gera o mesmo resultado, mas gera uma diferença de indicação) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Restrições de conversão usando linha como intermediário
Tem razão, nessa situação eu sempre faço com no_turn_left também. Vou acrescentar no tutorial. Mas quando se tem um cruzamento grande mesmo, não tem muito como fugir do dilema entre usar uma linha como intermediário ou um ponto e fazer alterações na geometria (a questão principal talvez seja quais são a menos pior nesse instante). 2014-02-26 17:40 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com: 2014-02-26 17:29 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Hm preciso fazer um exemplo disso. Mas acho que se você mudar a via intermediária por 1 nó só e proibir somente a conversão à esquerda, você acaba permitindo o retorno, não? Não em alguns casos. Exemplo: http://i.imgur.com/uiRNLqd.png Ao invés de fazer um proibido conversão com from A, via B, to C, pode-se fazer um proibido virar com from A, via n, to B. Essa proibição já impede de entrar no trecho B e portanto não vai dar para fazer um retorno para C. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Restrições de conversão usando linha como intermediário
2014-02-26 17:44 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Mas quando se tem um cruzamento grande mesmo, não tem muito como fugir do dilema entre usar uma linha como intermediário ou um ponto e fazer alterações na geometria (a questão principal talvez seja quais são a menos pior nesse instante). Isso, tem situação que não tem como escapar de usar um ou mais caminhos como via ou então alterar a geometria. Mas tem casos que não enxergo solução a não ser usar um caminho como via. Por exemplo: http://i.imgur.com/GKKytx4.png Quem vem de A só pode seguir para B (caminho verde). Não pode virar no caminho vermelho, para C. Quem vem de D não tem restrição: pode ir para B ou C Então não daria para utilizar uma restrição com nó ou no trecho v, porque também afetaria quem vem de D. A única solução é um proibido que tenha from A to C via v (com v sendo um way) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Tutorial de restrições de conversão
Ótima iniciativa, Fernando. Note que há muita gente nova entrando no projeto que fica meio perdida com tantas informações espalhadas. From: fernando.treb...@gmail.com Date: Wed, 26 Feb 2014 02:47:57 -0300 To: talk-br@openstreetmap.org Subject: [Talk-br] Tutorial de restrições de conversão Pessoal, Escrevi um tutorial detalhado sobre restrições de conversão usando o JOSM. O objetivo é que o tutorial possa levar uma pessoa do nível iniciante para o nível avançado nesse assunto. http://wiki.openstreetmap.org/wiki/Pt-br:Tutorial:Restri%C3%A7%C3%B5es_de_Convers%C3%A3o Vou relê-lo em breve para consertar eventuais problemas, mas aceito sugestões de melhorias (formas diferentes de explicar a mesma coisa, formas diferentes de colocar a mesma frase, etc.), correções, e sugestões de acréscimos. Bom proveito! -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Restrições de conversão usando linha como intermediário
Por isso que no Editor de Nós do Tracksource, de autoria do Paulo Carvalho, as restrições eram criadas por nós. Definindo-se 3 nós (no caso de curvas) ou 4 nós (no caso de retornos em U) dava para facilmente criar as restrições sem ter que quebrar nada. Se o compilador cgpsmapper que parou no tempo entendia as restrições, porque no mkgmap não funciona? Ou o problema não tem nada a ver com compilador? From: fernando.treb...@gmail.com Date: Wed, 26 Feb 2014 17:20:26 -0300 To: talk-br@openstreetmap.org Subject: Re: [Talk-br]Restrições de conversão usando linha como intermediário Um pouco diferente disso. Até há pouco tempo, as restrições no OSM envolviam sempre: 2 vias (entrada + saída) + 1 ponto de passagem. Recentemente, ampliaram a definição para permitir N vias de passagem. Você tem que quebrá-las porque você precisa indicar de qual direção para qual outra a restrição se refere. Se você usasse a via inteira, sem quebrar, não daria pra distinguir se o sentido é norte/sul ou leste/oeste (ou coisas assim). Olha o exemplo 2 aqui: http://wiki.openstreetmap.org/wiki/Pt-br:Tutorial:Restri%C3%A7%C3%B5es_de_Convers%C3%A3o#Cria.C3.A7.C3.A3o Se você não quebrar e usar apenas as vias X e Y inteiras com no_left_turn, não dá pra saber se é proibido dobrar de Y1 para X1 ou se a proibição é de Y2 para X2 (ou se é as duas coisas). 2014-02-26 16:09 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Segundo o que eu entendi restrições de manobra são relações apenas entre vias, por isso você tem que quebrá-las. Mas acho interessante propor a mudança da relação para nós e não vias. Em 26 de fevereiro de 2014 15:48, Erick de Oliveira Leal erickdeoliveiral...@gmail.com escreveu: Ontem que comecei a criar restrições, nunca tinha criado uma antes. No TrackSource não precisavamos quebrar uma via para fazer uma restrição nela, apenas ligavamos os pontos onde nao se podia. Quando fui fazer pelo josm, o plugin de restrições disse que eu tinha que quebrar e já até apresentava um botão pra automatizar isso. Então no JOSM sempre vai ser assim, não dá pra fazer por nós? Em 26 de fevereiro de 2014 15:45, Nelson A. de Oliveira nao...@gmail.com escreveu: 2014-02-26 15:24 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Opiniões? Eu pessoalmente prefiro manter a geometria correta da rodovia, mesmo que acabe ficando com uma restrição não-funcional. O que dá para fazer em alguns casos é substituir por uma restrição equivalente. Por exemplo, locais com proibido retornar + proibido virar à esquerda podem ser representados apenas com um proibido virar à esquerda (usando um nó como via). ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Tutorial de restrições de conversão
Fiz justamente pensando nessa gente nova. Se tiver dúvidas ou souber de dúvidas frequentes de outros, me manda que eu tento complementar o tutorial. 2014-02-26 18:12 GMT-03:00 Raffaello Bruno Limongi Freire raffaellobr...@hotmail.com: Ótima iniciativa, Fernando. Note que há muita gente nova entrando no projeto que fica meio perdida com tantas informações espalhadas. From: fernando.treb...@gmail.com Date: Wed, 26 Feb 2014 02:47:57 -0300 To: talk-br@openstreetmap.org Subject: [Talk-br] Tutorial de restrições de conversão Pessoal, Escrevi um tutorial detalhado sobre restrições de conversão usando o JOSM. O objetivo é que o tutorial possa levar uma pessoa do nível iniciante para o nível avançado nesse assunto. http://wiki.openstreetmap.org/wiki/Pt-br:Tutorial:Restri%C3%A7%C3%B5es_de_Convers%C3%A3o Vou relê-lo em breve para consertar eventuais problemas, mas aceito sugestões de melhorias (formas diferentes de explicar a mesma coisa, formas diferentes de colocar a mesma frase, etc.), correções, e sugestões de acréscimos. Bom proveito! -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Restrições de conversão usando linha como intermediário
Nesse caso, alterando a geometria, tem sim, mas não é o ideal. Você suprime v (transformando-a num ponto) e daí conecta A diretamente a B. Pra minimizar a confusão, A pode ser paralela a D e seguir bem próxima dela. Na interseção de A, B, C e D, você coloca todas as restrições. O resultado: - se A for bem próxima de D, a separação das duas só será visível com muita ampliação - as instruções de voz dadas pelo navegador GPS seriam corretas Isso funciona na nossa atual estrutura (do ponto de vista das aplicações). E eu concordo que queremos (e devemos) fugir disto, mas o dilema é ninguém suportar o caso ideal ainda. 2014-02-26 18:01 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com: 2014-02-26 17:44 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Mas quando se tem um cruzamento grande mesmo, não tem muito como fugir do dilema entre usar uma linha como intermediário ou um ponto e fazer alterações na geometria (a questão principal talvez seja quais são a menos pior nesse instante). Isso, tem situação que não tem como escapar de usar um ou mais caminhos como via ou então alterar a geometria. Mas tem casos que não enxergo solução a não ser usar um caminho como via. Por exemplo: http://i.imgur.com/GKKytx4.png Quem vem de A só pode seguir para B (caminho verde). Não pode virar no caminho vermelho, para C. Quem vem de D não tem restrição: pode ir para B ou C Então não daria para utilizar uma restrição com nó ou no trecho v, porque também afetaria quem vem de D. A única solução é um proibido que tenha from A to C via v (com v sendo um way) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Restrições de conversão usando linha como intermediário
Não ajudei. Eu sim fiz a ferramenta, sozinho. Desculpe o tom, mas é o fato. Em 26 de fevereiro de 2014 17:28, Erick de Oliveira Leal erickdeoliveiral...@gmail.com escreveu: O Paulo Carvalho sabe melhor pois ajudou a desenvolver as ferramentas. Eu só as usava. Em 26/02/2014 17:25, Fernando Trebien fernando.treb...@gmail.com escreveu: Ligavam os pontos? Interessante. Como funcionava isso, exatamente? A resposta é: sim, você sempre precisa quebrar. É preciso que as vias de entrada e saída sejam pedaços conectados, e que cada pedaço tenha como ponto extremo (ponto final): - o ponto intermediário (da interseção); ou - o início e o fim das vias intermediárias Depois dá uma lida nessas duas seções: - http://wiki.openstreetmap.org/wiki/Pt-br:Tutorial:Restri%C3%A7%C3%B5es_de_Convers%C3%A3o#Cria.C3.A7.C3.A3o - http://wiki.openstreetmap.org/wiki/Pt-br:Tutorial:Restri%C3%A7%C3%B5es_de_Convers%C3%A3o#Linha_como_intermedi.C3.A1rio E se tiver dúvidas já me avisa pra eu tentar tornar o tutorial mais claro e fácil de digerir. 2014-02-26 15:48 GMT-03:00 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: Ontem que comecei a criar restrições, nunca tinha criado uma antes. No TrackSource não precisavamos quebrar uma via para fazer uma restrição nela, apenas ligavamos os pontos onde nao se podia. Quando fui fazer pelo josm, o plugin de restrições disse que eu tinha que quebrar e já até apresentava um botão pra automatizar isso. Então no JOSM sempre vai ser assim, não dá pra fazer por nós? Em 26 de fevereiro de 2014 15:45, Nelson A. de Oliveira nao...@gmail.com escreveu: 2014-02-26 15:24 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Opiniões? Eu pessoalmente prefiro manter a geometria correta da rodovia, mesmo que acabe ficando com uma restrição não-funcional. O que dá para fazer em alguns casos é substituir por uma restrição equivalente. Por exemplo, locais com proibido retornar + proibido virar à esquerda podem ser representados apenas com um proibido virar à esquerda (usando um nó como via). ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Plugin confaltion do JOSM
Marcelo, abra um ticket sobre esses problemas: http://josm.openstreetmap.de/newticket Erro de introspecção já é difícil de diagnosticar sendo conhecedor do código, imagine sendo de fora... não trave com isso, passa para frente. Se alguém mais vir esses erros de Java aparecendo, não percam tempo tentando adivinhar, contate os desenvolvedores. Em 26 de fevereiro de 2014 16:53, Marcelo Pereira pereirahol...@gmail.comescreveu: Srs, Desculpem a demora em responder, estava enrolado em achar o Java 6 para instalação. Pois bem. Instalei o Ubuntu do zero, com o java 6. Usei os JOSMs 6502, 6409 e 6296 Sempre com o mesmo erro, consigo até listar os erros encontrados nos mapas, mas na hora de conflacionar, erro!!! Aliás, na versão 6296 o conflation nem carregou, deu pau na inicialização. Se alguem tiver uma combinação JOSM + JAVA funcional, por favor me avise. Ou outra ferramenta que faça a mesma coisa. Agradeço às dicas recebidas, Att, Marcelo Pereira Em 24 de fevereiro de 2014 19:13, Paulo Carvalho paulo.r.m.carva...@gmail.com escreveu: Pode ser mesmo biblioteca incompatível. Agora qual eu não sei. Estou sem condição de investigar isso. Estou com coisas mais fundamentais para investigar como a compilação com mkgmap. Em 24 de fevereiro de 2014 16:31, Fernando Trebien fernando.treb...@gmail.com escreveu: Esses erros de introspecção já foram relatados no bug tracker do plugin, mas o desenvolvedor parece ter meio que abandonado o projeto, ou pelo menos não o estar priorizando (afinal, se funciona com Java 6...). Lembro vagamente de ter lido algum stack trace que sugeria que o erro acontece numa das bibliotecas de que o plugin depende, uma das usadas para calcular a semelhança topológica entre as duas malhas. 2014-02-22 15:22 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com : Faz sentido usar JOSMs mais antigos. O erro postado pelo Marcelo parece ser um erro de introspecção (erro de funcionamento interno). A grosso modo o plugin não está falando a mesma língua do framework (JOSM). O desenvolvedor do plugin de conflação deve dar uma olhada nas APIs novas e removidas do JOSM. Em 22 de fevereiro de 2014 12:40, Erick de Oliveira Leal erickdeoliveiral...@gmail.com escreveu: Marcelo, vai testando com esses JOSMs mais antigos: http://josm.openstreetmap.de/download/Archiv/ Vai tentando com intervalos de 2 em 2 meses pra ser mais rapido Em 22 de fevereiro de 2014 12:35, Marcelo Pereira pereirahol...@gmail.com escreveu: Erick, Obrigado pela ajuda, segue o erro apresentado ERROR: java.lang.NoSuchMethodError: org.openstreetmap.josm.command.AddPrimitivesCommand.init(Ljava/util/List;Lorg/openstreetmap/josm/gui/layer/OsmDataLayer;)V java.lang.NoSuchMethodError: org.openstreetmap.josm.command.AddPrimitivesCommand.init(Ljava/util/List;Lorg/openstreetmap/josm/gui/layer/OsmDataLayer;)V at org.openstreetmap.josm.plugins.conflation.ConflateMatchCommand.init(ConflateMatchCommand.java:42) at org.openstreetmap.josm.plugins.conflation.ConflationToggleDialog$ConflateAction.conflateMatchActionPerformed(ConflationToggleDialog.java:570) at org.openstreetmap.josm.plugins.conflation.ConflationToggleDialog$ConflateAction.actionPerformed(ConflationToggleDialog.java:547) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2018) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2341) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:252) at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:289) at java.awt.Component.processMouseEvent(Component.java:6505) at javax.swing.JComponent.processMouseEvent(JComponent.java:3320) at java.awt.Component.processEvent(Component.java:6270) at java.awt.Container.processEvent(Container.java:2229) at java.awt.Component.dispatchEventImpl(Component.java:4861) at java.awt.Container.dispatchEventImpl(Container.java:2287) at java.awt.Component.dispatchEvent(Component.java:4687) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4832) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4492) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4422) at java.awt.Container.dispatchEventImpl(Container.java:2273) at java.awt.Window.dispatchEventImpl(Window.java:2719) at java.awt.Component.dispatchEvent(Component.java:4687) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:735) at java.awt.EventQueue.access$200(EventQueue.java:103) at java.awt.EventQueue$3.run(EventQueue.java:694) at java.awt.EventQueue$3.run(EventQueue.java:692) at java.security.AccessController.doPrivileged(Native Method) at
Re: [Talk-br] Nomes antigos
Valeu! Em 26 de fevereiro de 2014 21:01, Arlindo Pereira openstreet...@arlindopereira.com escreveu: Basta separar os valores por ; . Por exemplo: http://www.openstreetmap.org/way/130347317#map=18/-22.90260/-43.17552 []s Arlindo 2014-02-26 20:57 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Pessoal, Sei que existe a tag old_name. É possível registrar nomes mais antigos? Ex.: aqui no Rio a Av. Lúcio Costa já foi chamada Av. Sernambetiba, que por sua vez já foi chamada Av. Litorânea, seu nome original. O bairro onde moro, por exemplo, já teve 3 nomes. Outros bairros do Rio já tiveram mudança de nomes semelhante. []s Paulo ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Nomes antigos
Isso vale para outras tags que possam ter mais de um valor, como alt_name (nomes populares pelos quais a via é conhecida), phone etc. []s 2014-02-26 21:04 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Valeu! Em 26 de fevereiro de 2014 21:01, Arlindo Pereira openstreet...@arlindopereira.com escreveu: Basta separar os valores por ; . Por exemplo: http://www.openstreetmap.org/way/130347317#map=18/-22.90260/-43.17552 []s Arlindo 2014-02-26 20:57 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Pessoal, Sei que existe a tag old_name. É possível registrar nomes mais antigos? Ex.: aqui no Rio a Av. Lúcio Costa já foi chamada Av. Sernambetiba, que por sua vez já foi chamada Av. Litorânea, seu nome original. O bairro onde moro, por exemplo, já teve 3 nomes. Outros bairros do Rio já tiveram mudança de nomes semelhante. []s Paulo ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Problema de usabilidade do editor de endereços do iD
Atualização: O campo addr:housename foi retirado do iD, agora só pode ser incluído manualmente usando etiquetas. Um usuário (não-brasileiro) retirou o campo depois de ver que estava confundindo usuários em outros países. O *pull request* se encontra no seguinte link: https://github.com/openstreetmap/iD/pull/2127 Sugiro agora retirar a tradução de addr:housename como Complemento. Abs, João ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Proposta de padronização de lombadas no Brasil
Olha, vendo essa etiqueta traffic_calming=table, eu vou segurar a minha proposta por um bom tempo até conseguir investigar melhor essa situação. A pergunta é: existe alguma lombada de 3+ metros que não seja um traffic_calming=table? (ou seja, que não tenha o topo achatado). Sinceramente, nunca vi, e olha que já vi uns 4-5 traffic_calming=table aqui na minha cidade. Estou pensando que traffic_calming=bump é menor que 1,5m, mas vou tirar umas fotos aqui pra montar melhor o meu caso (isso vai demorar umas duas semanas pelo menos). Quando às depressões, acho que teria que ser proposto uma nova etiqueta ( traffic_calming=depression ou algo assim). Alguém tem uma foto dela? Abs, João Em 25 de fevereiro de 2014 18:46, Arlindo Pereira openstreet...@arlindopereira.com escreveu: Acho que as depressões poderiam ser bump/hump com depression=yes ou algo assim, visto que é a mesma função. Ou propor um valor traffic_calming=depression. O que vocês acham? Tenho essa foto aqui, que não mostra a depressão em si mas dá uma ideia, hehe. Isso foi em Foz do Iguaçu :P Procurar por depressão na pista no Google Imagens retorna resultados semelhantes. :P []s Arlindo 2014-02-25 16:54 GMT-03:00 Marcelo Pereira pereirahol...@gmail.com: Considerações, minhas : - Aqui pros lados do NE tb é conhecida como quebra-molas. - Já vi muitos casos de lombadas feitas pela própria população, nota-se a diferença pela total falta de padrão, mas estas tendem a ser mais altas que as oficiais, já vi até triangulares ( exemplo http://goo.gl/RC3ogE). Neste caso, que tag usar ? - Já vi lombadas de terra, em vias do mesmo tipo, e aí ? - Aqui perto de casa, tem uma lombada mais larga, que traz no seu corpo uma faixa de pedestres ( exemplo http://goo.gl/16S98g ), como se classificaria isso ? Aproveitando o embalo, não sei se ainda existem, mas cheguei a ver lombadas invertidas, ou seja, depressões na pista usadas como lombadas. Isso recebe tag ? Marcelo Pereira Em 25 de fevereiro de 2014 16:06, Fernando Trebien fernando.treb...@gmail.com escreveu: Por mim tá perfeito. On Feb 25, 2014 3:38 PM, John Packer john.pack...@gmail.com wrote: Pessoal, em uma discussão recente aqui na lista, percebi que tem duas formas diferentes de etiquetar uma lombada: traffic_calming=bump e traffic_calming=hump. Vi que não havia uma padronização quanto a isso no Brasil, então levantei as mangas e comecei a pesquisar. Em primeiro lugar descobri que tem outros nomes para uma lombada: - lomba (que é sinônimo de lombada) - quebra-mola (que é utilizado no RS) - ondulação transversal (que é um termo mais abrangente) E descobri que existem sim dois tipos de lombada: *Tipo I* e *Tipo II*. Como podem ver no seguinte link: http://www.cliqueautomotivo.com.br/index.php?pg=sobrerodas/lombada-ou-quebra-molas O tipo 1 é menor que o tipo 2, mas é também mais curto, forçando o usuário a reduzir mais a velocidade do que no tipo 2. Nas definições de *Bump* que vi, era assim mesmo, com a única diferença sendo que *Bump* poderia ter uma altura maior do que *Hump*em alguns casos. Logo, a minha proposta de padronização é a seguinte: - em lombadas Tipo I = traffic_calming=bump - em lombadas Tipo II = traffic_calming=hump - se não se encaixar em um desses tipos, deve ser etiquetado o mais próximo, de acordo com o *comprimento* Abs, João ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- ... Edileuz, eu não tem nada a ver com Creuza, É mentira da Ivete, não é meu esse caniveete... Halley, Luiz - Poeta, Cantor, Compsitor ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-de] Keine Namen in Mapnik und anderen Karten
Am 26.02.2014 00:03, schrieb Peter Wendorff: Mehr tut area=yes aber nicht, und wenn das tatsächlich DER Indikator in Mannheim ist, um die benannten Blöcke darzustellen, dann ist das ein Problem. Moin, die Mannheimer Quadrate sind getaggt als: place=neighbourhood area=yes name=A1 https://www.openstreetmap.org/way/165439220 Eventuell fehlt also die Regel für Flächen die mit place=neighbourhood gekennzeichnet sind. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Keine Namen in Mapnik und anderen Karten
Bernd Wurst bernd at bwurst.org writes: accessforestry bicycle yes foot yes highway track name Hoblersbergweg tracktype grade2 Auch wenn Off-Topic: Ich würde bicycle = yes und foot = yes rausnehmen und das access = forestry auf motor_vehicle = forestry umstellen. Das man einen Wald/Feldweg zu Fuß und mit dem Fahrrad benutzen kann ist IMHO selbstverständlich. Die beschilderte Einschränkung bezieht sich lediglich auf motorisiertes Fahrzeug. Das aber nur am Rande. Siehe auch: http://wiki.openstreetmap.org/wiki/DE:Key:access Was muss ich nun ändern, dass die Namen wieder auftauchen? Der Frage schließe ich mich an. Ist ja nicht so, dass Wirtschaftswege dermaßen üppig benamst wären, dass das die Karte unübersichtlich machen würde. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Keine Namen in Mapnik und anderen Karten
Am 26.02.2014 08:43, schrieb Bernd Wurst: Hallo. Am 26.02.2014 00:01, schrieb Frederik Ramm: die Straßen in den Naherholungsgebieten zwischen den Vororten (highway = track) werden nun auch namenlos angezeigt, obwohl sie Straßennamen tragen, bei Fußwegen (path oder footway) mit Namen genauso. Da muss man sich jetzt halt überlegen, ob man bei solchen Wegen gern Namen angezeigt haben möchte, und wenn ja, trägt man das ein. Ist ja kein Hexenwerk. Wo trägt man das ein? Ich habe hier sehr viele Feld- und Waldwege, deren Namen nun komplett verschwunden sind. Tagging ist etwa so: accessforestry bicycle yes foot yes highway track name Hoblersbergweg tracktype grade2 Was muss ich nun ändern, dass die Namen wieder auftauchen? Das sieht richtig getaggt aus. Die Rendering-Regeln müssen so angepasst werden, dass bei highway=track wieder ein Name gerendert wird. Das kann nur der Style-Ersteller machen und nicht der einzelne Mapper. Ich würde mal 1-2 Wochen warten und wenn dann der Rendering-Style nmoch nciht gefixt ist ein Issue bei Github ( https://github.com/gravitystorm/openstreetmap-carto ) öffnen. Grüße, Theodin Gruß, Bernd ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] BING hat neue aktuelle Bilder veröffentlich
Nachdem ich so lange gewartet habe, ist es nun endlich so weit. Es gibt neue BING-Bilder auch für das Bayr.Oberland. Nun wartet viel Arbeit auf die OSMler hier in dieser Gegend. Aber Vorsicht, ich habe festgestellt, dass da ein Versatz im Vergleich zu Bayern 2m vorhanden ist. Gruß hike39 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Keine Namen in Mapnik und anderen Karten
Hallo. Am 26.02.2014 10:21, schrieb Manuel Reimer: Auch wenn Off-Topic: Ich würde bicycle = yes und foot = yes rausnehmen und das access = forestry auf motor_vehicle = forestry umstellen. Das man einen Wald/Feldweg zu Fuß und mit dem Fahrrad benutzen kann ist IMHO selbstverständlich. Die beschilderte Einschränkung bezieht sich lediglich auf motorisiertes Fahrzeug. Das aber nur am Rande. Ja, ich hab das aus dem Objekt auf der OSM-Seite raus kopiert. Die von dir genannten Tags habe nicht ich gesetzt, die sind mir auch erst heute aufgefallen. Aber ich wollte nicht lügen :-) und daher daher die Tags hier rein kopiert, die bei mir dazu führen dass alte Kacheln noch einen Namen haben und neu gerenderte nicht mehr. Gruß, Bernd signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Keine Namen in Mapnik und anderen Karten
Hallo Bernd, was hältst Du davon, konkrete Probleme zu verlinken, damit man konkrete Fragen stellen kann, was da was ist oder sein soll. Dass ein Name am Goetheplatz fehlt, hattest du geschrieben. Dass das zusammen mit highway=pedestrian und area=yes korrekt gerendert werden sollte, hast du hier auch schon lesen können. Wenn das nicht korrekt dargestellt wird, ist das meines Erachtens ein Fehler im aktuellen Rendering - dann muss man eine entsprechende Fehlermeldung machen; auch dazu wäre ein konkreter Verweis auf eine Stelle in der Karte sinnvoll. Wer aber sollte jetzt ein Ticket aufgrund einer Fehlermeldung aufmachen, die nur auf Hörensagen beruht, weil niemand außer dir das direkt überprüfen kann (denn Goetheplatz gibt's schon ganz schön häufig). Also: Gib uns einen Link und es wird jemand versuchen, dir zu helfen - jedenfalls ist das meistens der Fall. Soviel also zu deiner Frage was denn noch. Gruß Peter Am 26.02.2014 08:46, schrieb Bernd Wurst: Hallo. Am 26.02.2014 08:31, schrieb Walter Nordmann: Bernhard Weiskopf wrote Wie trägt man das jetzt ein? Genügt name = ... nicht mehr? Ja, name=* reicht nicht mehr aus - und das ist gut so! Ja, aber selbst highway=... und name=... reicht scheinbar nicht aus? Was denn noch? render_this_name=yes oder wie? :-) ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Keine Namen in Mapnik und anderen Karten
Hallo Peter. Zunächst: Watch your tone. Ehrlich. Am 26.02.2014 11:00, schrieb Peter Wendorff: Hallo Bernd, was hältst Du davon, konkrete Probleme zu verlinken, damit man konkrete Fragen stellen kann, was da was ist oder sein soll. Dass ein Name am Goetheplatz fehlt, hattest du geschrieben. Nein, habe ich nicht geschrieben. Dass das zusammen mit highway=pedestrian und area=yes korrekt gerendert werden sollte, hast du hier auch schon lesen können. Ja, betrifft mich aber null komma gar nicht. Wer aber sollte jetzt ein Ticket aufgrund einer Fehlermeldung aufmachen, die nur auf Hörensagen beruht, weil niemand außer dir das direkt überprüfen kann (denn Goetheplatz gibt's schon ganz schön häufig). Ich habe nur von einigen Waldwegen gesprochen. Eigentlich sind es alle Waldwege. Ich kann dir hunderte Links schicken. Oder du schaust einfach irgend einen x-beliebigen Waldweg an. Also: Gib uns einen Link und es wird jemand versuchen, dir zu helfen - jedenfalls ist das meistens der Fall. Soviel also zu deiner Frage was denn noch. Die Frage war ganz konkret: Was ist bei einem normalen Weg denn außer name noch nötig um ein Redering des Namens zu erwirken. Dass es *kein* area-Tag geben soll konnte man hier heraus lesen. Aber meine Wege haben kein area-Tag. Meine Mutmaßung ist ja, dass hier der Style von highway=* auf einige wenige explizit eingetragene Werte eingeschränkt wurde. Das kann man machen, muss dann aber auch alle etablierten Werte berücksichtigen. Bisher scheint track kein gültiger Wegtyp in diesem Sinne zu sein. Ich seh's irgendwie nicht ein, für ein Problem einen Bugreport [1] auf zu machen das derart offensichtlich ist. Wer das verbockt hat, soll sich bitte auch darum kümmern dass das gefixed wird. [1]: Ich müsste mir dafür schließlich erst noch einen github-Account machen, den ich nicht haben will. Gruß, Bernd signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] SOTM-EU Einsendeschluss für Vorträge verlängert
Hallo, der Einsendeschluss für Vorträge bei der SOTM EU in Karlsruhe im Juni ist verlängert worden - bis zum 17. März. Wenn Ihr also noch nicht dazu gekommen seit, Euer Thema zu formulieren, habt Ihr noch ein wenig mehr Zeit dazu. Einsenden könnt Ihr auf http://www.sotm-eu.org/de/presentations/new wo Ihr auch weitere Details zur Konferenz findet. -- Christoph Hormann http://www.imagico.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Keine Namen in Mapnik und anderen Karten
Mir ist ehrlich gesagt nicht ganz klar was die Aufregung soll. 2 von 5 Karten auf openstreetmap.org zeigen weiterhin Namen von tracks an, Beispiel http://www.openstreetmap.org/#map=18/48.98690/8.35193layers=C . Des weiteren kann man auch weiterhin beliebige Karten produzieren, die die Namen anzeigen und weiter ist es auch nicht so, dass irgendjemand gesagt hat, dass Namen bei tracks nie wieder angezeigt werden. Es ist ja auch grade weil der Standardstil jeden Name Tag angezeigt hat, dass man jetzt zuerst fast auf Null zurück muss und sich durch alle Fälle durcharbeiten und eine entsprechende Entscheidung treffen muss. Simon ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Keine Namen in Mapnik und anderen Karten
Am 26.02.2014 11:20, schrieb Bernd Wurst: Hallo Peter. Zunächst: Watch your tone. Ehrlich. Am 26.02.2014 11:00, schrieb Peter Wendorff: Hallo Bernd, was hältst Du davon, konkrete Probleme zu verlinken, damit man konkrete Fragen stellen kann, was da was ist oder sein soll. Dass ein Name am Goetheplatz fehlt, hattest du geschrieben. Nein, habe ich nicht geschrieben. Stimmt, du hattest nur gefragt (Mail von gestern, 25.2., 23:12): Wie trägt man zukünftig den Goetheplatz ein, damit der Name des allseits bekannten Platzes auf der Karte erscheint? Ich nehme an, der Name von area = yes wird dann nicht mehr angezeigt. Vielleicht hab ich da also einen konkreten Fehlerfall reininterpretiert, den es nicht einmal gab oder gibt - dann entschuldige ich mich für den Ton (erlaube mir aber, die Frage zu stellen, was du damit eigentlich erfragen wolltest). Dass das zusammen mit highway=pedestrian und area=yes korrekt gerendert werden sollte, hast du hier auch schon lesen können. Ja, betrifft mich aber null komma gar nicht. Sondern? Was betrifft dich denn dann? Denn die Frage hast du ja schon gestellt, zumindest ist die Mail bei mir so eingegangen. Was genau du brauchst, hast du ja nicht geschrieben - ich weiß nur, dass es um irgendeinen der Goetheplätze geht, die es gibt. Wer aber sollte jetzt ein Ticket aufgrund einer Fehlermeldung aufmachen, die nur auf Hörensagen beruht, weil niemand außer dir das direkt überprüfen kann (denn Goetheplatz gibt's schon ganz schön häufig). Ich habe nur von einigen Waldwegen gesprochen. Eigentlich sind es alle Waldwege. Ich kann dir hunderte Links schicken. Oder du schaust einfach irgend einen x-beliebigen Waldweg an. Das Waldweg-Thema ist ein anderes und doch geklärt - da fehlt noch die Render-Regel, die beim Catch-All weggefallen ist, da kann man gucken, ob es ein Ticket gibt und bei Bedarf eins erstellen, einen Patch einreichen etc., darauf habe ich mich aber nicht bezogen. Also: Gib uns einen Link und es wird jemand versuchen, dir zu helfen - jedenfalls ist das meistens der Fall. Soviel also zu deiner Frage was denn noch. Die Frage war ganz konkret: Was ist bei einem normalen Weg denn außer name noch nötig um ein Redering des Namens zu erwirken. Dass es *kein* area-Tag geben soll konnte man hier heraus lesen. Aber meine Wege haben kein area-Tag. das area-Tag ist nicht ausschlaggebend fürs Rendering; es ist aber notwendig, um ein lineares feature als Fläche darzustellen. waldwege: Da fehlt die Rendering-Regel, Goetheplatz: da fehlt das Wissen darüber, was da überhaupt drangetagged ist - und das verweigerst du ja weiterhin (oder es interessiert dich tatsächlich nicht mehr). Meine Mutmaßung ist ja, dass hier der Style von highway=* auf einige wenige explizit eingetragene Werte eingeschränkt wurde. Das kann man machen, muss dann aber auch alle etablierten Werte berücksichtigen. Bisher scheint track kein gültiger Wegtyp in diesem Sinne zu sein. Ich seh's irgendwie nicht ein, für ein Problem einen Bugreport [1] auf zu machen das derart offensichtlich ist. Wer das verbockt hat, soll sich bitte auch darum kümmern dass das gefixed wird. Ich glaube, bei konkreten Fehlermeldungen (wie gesagt: ich red vom Goetheplatz) würde das jemand übernehmen; spätestens auf eine direkte Bitte hin. Aber aus wagen Aussagen ein Ticket zu bauen ist etwas mehr Arbeit als sich bei github anzumelden. Wer das verbockt hat hat im Zuge dessen etliche andere Fehler behoben und damit die Gesamtlage im Rendering eher verbessert; zumindest aber langfristig eine richtige Grundlage gelegt, um gezielt eine korrekte Darstellung genau da zu erzielen, wo sie gewünscht wird. Wenn Du mit github ein Problem hast, frag doch einfach freundlich nach, beschreibe das Problem konkret und so, wie du es auch in ein Ticket schreiben würdest, und bitte darum, dass daraus jemand ein Ticket macht, ich bin sicher, dass dir das nicht verwehrt wird. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Inseln und Inselgruppen
Vielleicht ist der Tread Namen in Mapnik eine gute Gelegenheit, die Frage zur Benennung von Inseln und Insel-Gruppen wieder aufzunehmen. Dann könnte man das Rendering vielleicht gleich mit erledigen... Es ging darum, wie man Bedeutung und Dominanz der Inseln irgendwie abbilden/berechnen kann... Ziel wäre, dass man die Inselgruppen und Inseln genauso schön sieht wie in einem guten Schulatlas - nur halt passend zu den Zoomstufen :-) Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vulkane und natural=crater
On Tue, Feb 25, 2014 at 10:46:39PM +0100, Martin Koppenhoefer wrote: Am 25. Februar 2014 21:08 schrieb Richard Z. ricoz@gmail.com: So ein ausgedehntes Lavafeld halte ich sehr wohl für ein geografisches Feature +1 natural=lava_field ? war auch mein erster Gedanke, aber wo es schon seit Ewigkeiten natural=lava mit exakt der gleichen Bedeutung im wiki gibt bin ich eher geneigt das lava zu übernehmen als auf lava_field zu ändern? Was macht man mit flüssigem Lava? Sind zum Teil richtige Flüsse die auch gemappt werden könnten, und z.T. unterirdisch (lava pipes). lavaway als key? ;-) sowas habe ich gedacht. Oder man versucht die Material-Flüsse zu generalisieren - es gibt noch allerlei was in der Natur fliessen kann, mir fallen gerade Gletscher, Asfalt, Erdrutsche ein. Richard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vulkane und natural=crater
Am 26. Februar 2014 15:33 schrieb Richard Z. ricoz@gmail.com: +1 natural=lava_field ? war auch mein erster Gedanke, aber wo es schon seit Ewigkeiten natural=lava mit exakt der gleichen Bedeutung im wiki gibt bin ich eher geneigt das lava zu übernehmen als auf lava_field zu ändern? hat ja nicht genau die gleiche Bedeutung ;-) und ist auch nicht so extrem in Verwendung (gut, es gibt wohl auch mehr Parkplätze als Lavafelder in der Welt). Zum einen ist es sprachlich unscharf und daher grundsätzlich anfällig für Verwechslungen, zum anderen ist laut der Wikiseite natural=lava nur für Lavafelder, die nahe an einem Vulkan liegen (andere kenne ich zugegebenermaßen zwar bisher auch nicht, aber wenn es sowieso keine anderen gäbe müsste man sie ja auch nicht ausschließen, oder?). Es gibt auch schon lava_channel und lava_tunnel als natural Werte, da fügte sich lava_field m.E. besser ein als ein generisches lava. (Allgemein ist übertriebene Sprachfaulheit bei tags eher schlecht, d.h. wenn man einen spezifischen Wert definieren will, aber einen generischen Term benutzt). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vulkane und natural=crater
On Tue, Feb 25, 2014 at 10:29:28PM +0100, Christoph Hormann wrote: On Tuesday 25 February 2014, Richard Z. wrote: natural=lava halte ich weniger für einen guten tag, weil es kein geografisches Feature sondern ein Material ist. Auch halte ich es für schwierig, das abzugrenzen (alle Erstarrrungsgesteine sind im Prinzip Lava, oder?). Tendeziell wäre m.E. landcover=lava besser als natural, mit den vg. Einschränkungen. So ein ausgedehntes Lavafeld halte ich sehr wohl für ein geografisches Feature und landcover würde ich auch nicht für geologische Features verwenden wollen. Generell gilt denke ich beim Tagging: nur, weil es irgendwo etwas gibt, das sich recht zweifelsfrei und sinnvoll mit einem bestimmten Tag beschreiben ließe bedeutet das nicht, dass dieses Tag auch tatsächlich nützlich ist. Wenn Du nämlich nicht irgendwelche willkürlichen Alters- oder Größengrenzen ziehen möchtest würdest Du am Ende teilweise Gebiete von Millionen Quadratkilometern Größe so taggen (z.B. weite Teile Sibiriens). Ein erstarrter aber junger Lavastrom ließe sich schlicht und einfach als natural=bare_rock, ggf. mit Zusatztags mappen. Für ältere, bereits bewachsene Lavaströme, wo man primär dann den Bewuchs mappt, würde sich etwas wie geological=lava_flow anbieten. Erstarrte Lavaströme unterscheiden sich recht stark von bare_rock und unterteilen sich auch noch in weitere Untertypen. Die sichtbare Konsistenz variiert zwichen Lava-geröll und eben bare_rock. Trotzdem haben sie auch Gemeinsamkeiten die ein zusammenfassendes Tag m.E. rechtfertigen. Vergleichbares gilt denke ich auch für Krater - das ist im Allgemeinen zunächst erst einmal natural=cliff|ridge. Es gibt nämlich auch oft Fälle in vulkanischen Gebieten, wo die Mechanismen der Entstehung kraterförmiger Strukturen garnicht so eindeutig feststellbar sind. +1 Was macht man mit flüssigem Lava? Sind zum Teil richtige Flüsse die auch gemappt werden könnten, und z.T. unterirdisch (lava pipes). Ein noch flüssiger Lavastrom lässt sich kaum sinnvoll mappen, da er seine Form und Ausdehnung permanent ändert. Das einzig sinnvolle Mapping flüssiger Lava wäre bei Lavaseen - erfasst ist das wohl derzeit nur beim Nyiragongo: Ich kenne das Phänomen vom Kilauea, daß die Lavaströme zum Teil über viele Jahre völlig stabil verlaufen, meist unterirdisch. Wenn sich mal was ändert sind es meistwenige Meter pro Monat. Das ist dann sicherlich stabil genug um gemappt zu werden und auch sehr wichtig, als Toristenatraktion und Gefahrenstelle. Sofern sich jemand darum kümmern will hätte ich auch nichts dagegen wenn auch Lavaströme gemappt werden die sich jeden Monat um einige Meter weiterschieben. Richard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Inseln und Inselgruppen
Am 26. Februar 2014 15:24 schrieb Markus liste12a4...@gmx.de: Es ging darum, wie man Bedeutung und Dominanz der Inseln irgendwie abbilden/berechnen kann... Ziel wäre, dass man die Inselgruppen und Inseln genauso schön sieht wie in einem guten Schulatlas - nur halt passend zu den Zoomstufen :-) sobald aufwendige Berechnungen ins Spiel kommen, ist die Standard-OSM-Mapnik Karte weniger geeignet, weil die mit dynamischen Daten arbeitet, und möglichst ressourcenschonend operieren soll. Braucht man aber auch nur für den letzten Schliff (d.h. für den Standard guter Schulatlas durchaus schon, falls man das überhaupt automatisch erreichen kann), während das Rendern von Archipelen und Inselnamen schon mit weniger Aufwand verbessert werden könnte (die Größe der Insel liegt vor in der db, wenn nicht nur ein node getaggt ist, und auch die Einwohnerzahl ist oft vorhanden, beides wird derzeit aber noch nicht berücksichtigt AFAIK, Archipelnamen werden AFAIK noch gar nicht gerendert). Schreib' doch mal ein Ticket und sieh, wie man Dir antwortet, vielleicht greift es ja jemand auf, derzeit passiert viel am Stil. Nochmal kurz zum Schulatlas: der hat allerdings nur eine grobmaßstäbliche Karte, das schlechtere Ergebnis beim Vergleich in diesen groben Zoomstufen gleichen wir m.E. mehr als aus, dadurch, dass wir zoomen können. ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Keine Namen in Mapnik und anderen Karten
Ich mach ja kein Tofu normalerweise aber hier kann ich nicht Sachbezogen antworten: Du legst mir in den Mund, dass ich irgendwas über irgend einen Goetheplatz geschrieben hätte. Habe ich nie. Ich weiß nichts von einem Goetheplatz. Lass das bitte. Am 26.02.2014 11:57, schrieb Peter Wendorff: Am 26.02.2014 11:20, schrieb Bernd Wurst: Hallo Peter. Zunächst: Watch your tone. Ehrlich. Am 26.02.2014 11:00, schrieb Peter Wendorff: Hallo Bernd, was hältst Du davon, konkrete Probleme zu verlinken, damit man konkrete Fragen stellen kann, was da was ist oder sein soll. Dass ein Name am Goetheplatz fehlt, hattest du geschrieben. Nein, habe ich nicht geschrieben. Stimmt, du hattest nur gefragt (Mail von gestern, 25.2., 23:12): Wie trägt man zukünftig den Goetheplatz ein, damit der Name des allseits bekannten Platzes auf der Karte erscheint? Ich nehme an, der Name von area = yes wird dann nicht mehr angezeigt. Vielleicht hab ich da also einen konkreten Fehlerfall reininterpretiert, den es nicht einmal gab oder gibt - dann entschuldige ich mich für den Ton (erlaube mir aber, die Frage zu stellen, was du damit eigentlich erfragen wolltest). Dass das zusammen mit highway=pedestrian und area=yes korrekt gerendert werden sollte, hast du hier auch schon lesen können. Ja, betrifft mich aber null komma gar nicht. Sondern? Was betrifft dich denn dann? Denn die Frage hast du ja schon gestellt, zumindest ist die Mail bei mir so eingegangen. Was genau du brauchst, hast du ja nicht geschrieben - ich weiß nur, dass es um irgendeinen der Goetheplätze geht, die es gibt. Wer aber sollte jetzt ein Ticket aufgrund einer Fehlermeldung aufmachen, die nur auf Hörensagen beruht, weil niemand außer dir das direkt überprüfen kann (denn Goetheplatz gibt's schon ganz schön häufig). Ich habe nur von einigen Waldwegen gesprochen. Eigentlich sind es alle Waldwege. Ich kann dir hunderte Links schicken. Oder du schaust einfach irgend einen x-beliebigen Waldweg an. Das Waldweg-Thema ist ein anderes und doch geklärt - da fehlt noch die Render-Regel, die beim Catch-All weggefallen ist, da kann man gucken, ob es ein Ticket gibt und bei Bedarf eins erstellen, einen Patch einreichen etc., darauf habe ich mich aber nicht bezogen. Also: Gib uns einen Link und es wird jemand versuchen, dir zu helfen - jedenfalls ist das meistens der Fall. Soviel also zu deiner Frage was denn noch. Die Frage war ganz konkret: Was ist bei einem normalen Weg denn außer name noch nötig um ein Redering des Namens zu erwirken. Dass es *kein* area-Tag geben soll konnte man hier heraus lesen. Aber meine Wege haben kein area-Tag. das area-Tag ist nicht ausschlaggebend fürs Rendering; es ist aber notwendig, um ein lineares feature als Fläche darzustellen. waldwege: Da fehlt die Rendering-Regel, Goetheplatz: da fehlt das Wissen darüber, was da überhaupt drangetagged ist - und das verweigerst du ja weiterhin (oder es interessiert dich tatsächlich nicht mehr). Meine Mutmaßung ist ja, dass hier der Style von highway=* auf einige wenige explizit eingetragene Werte eingeschränkt wurde. Das kann man machen, muss dann aber auch alle etablierten Werte berücksichtigen. Bisher scheint track kein gültiger Wegtyp in diesem Sinne zu sein. Ich seh's irgendwie nicht ein, für ein Problem einen Bugreport [1] auf zu machen das derart offensichtlich ist. Wer das verbockt hat, soll sich bitte auch darum kümmern dass das gefixed wird. Ich glaube, bei konkreten Fehlermeldungen (wie gesagt: ich red vom Goetheplatz) würde das jemand übernehmen; spätestens auf eine direkte Bitte hin. Aber aus wagen Aussagen ein Ticket zu bauen ist etwas mehr Arbeit als sich bei github anzumelden. Wer das verbockt hat hat im Zuge dessen etliche andere Fehler behoben und damit die Gesamtlage im Rendering eher verbessert; zumindest aber langfristig eine richtige Grundlage gelegt, um gezielt eine korrekte Darstellung genau da zu erzielen, wo sie gewünscht wird. Wenn Du mit github ein Problem hast, frag doch einfach freundlich nach, beschreibe das Problem konkret und so, wie du es auch in ein Ticket schreiben würdest, und bitte darum, dass daraus jemand ein Ticket macht, ich bin sicher, dass dir das nicht verwehrt wird. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vulkane und natural=crater
Am 26. Februar 2014 15:50 schrieb Martin Koppenhoefer dieterdre...@gmail.com: +1 natural=lava_field ? war auch mein erster Gedanke, aber wo es schon seit Ewigkeiten natural=lava mit exakt der gleichen Bedeutung im wiki gibt bin ich eher geneigt das lava zu übernehmen als auf lava_field zu ändern? Übrigens, das natural=lava gibt es keineswegs seit Ewigkeiten. https://wiki.openstreetmap.org/w/index.php?title=Tag:natural%3Dlavaaction=history Da hat mal jemand eine leere Seite angelegt, dann hat jemand draufgeschrieben dass die Bedeutung des tags unklar sei, woraufhin ein dritter, augenscheinlich bis dato noch überhaupt nicht weiter in Erscheinung getretener Benutzer ein Konto angelegt hat, und sich berufen sah, ohne weitere Diskussion einfach mal was hinzuschreiben. Wenn der tag durch einen normalen Prozess gegangen wäre, wäre er vermutlich besser gewählt und besser definiert ;-) Dass das bisher noch nicht weiter aufgefallen ist liegt vermutlich nur daran, dass es sich um einen kaum verwendeten tag für ein kaum auftretendes Phänomen handelt, das ganze also sozusagen unterhalb des Radars geblieben ist. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Keine Namen in Mapnik und anderen Karten
Am 26. Februar 2014 08:46 schrieb Bernd Wurst be...@bwurst.org: Ja, aber selbst highway=... und name=... reicht scheinbar nicht aus? Was denn noch? render_this_name=yes oder wie? :-) eintragen bei github / carto osm Dass tracks und pedestrians derzeit keine Namen haben (und service mit service=alley) ist allerdings bereits bekannt und es wird auch daran gearbeitet. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Keine Namen in Mapnik und anderen Karten
Am 26. Februar 2014 10:21 schrieb Manuel Reimer manuel.s...@nurfuerspam.de : Auch wenn Off-Topic: Ich würde bicycle = yes und foot = yes rausnehmen und das access = forestry auf motor_vehicle = forestry umstellen. Das man einen Wald/Feldweg zu Fuß und mit dem Fahrrad benutzen kann ist IMHO selbstverständlich. so oder so sind Krankenfahrstühle wohl nicht berücksichtigt bei diesen beiden Taggingvarianten. den key für forestry von access zu motor_vehicle finde ich auch OK, das bicycle=yes und ggf. auch das foot=yes würde ich aber drin lassen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Keine Namen in Mapnik und anderen Karten
Am 26. Februar 2014 16:38 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 26. Februar 2014 10:21 schrieb Manuel Reimer manuel.s...@nurfuerspam.de : Auch wenn Off-Topic: Ich würde bicycle = yes und foot = yes rausnehmen und das access = forestry auf motor_vehicle = forestry umstellen. Das man einen Wald/Feldweg zu Fuß und mit dem Fahrrad benutzen kann ist IMHO selbstverständlich. so oder so sind Krankenfahrstühle wohl nicht berücksichtigt bei diesen beiden Taggingvarianten. den key für forestry von access zu motor_vehicle finde ich auch OK, das bicycle=yes und ggf. auch das foot=yes würde ich aber drin lassen. Da hat Martin wohl leider recht. Da die erlaubte Benutzungsart für verschiedene Fortbewegungsmittel in Wäldern schon von Bundesland zu Bundesland verschieden ist, bleibt wohl nichts anderes, als ein ausdrückliches access-Tagging. Für Feldwege (track zwischen Feldern) ist dann schon wieder ein anderes Gesetz zuständig. Entweder man baut für jedes Bundesland eine eigene Routingregel unter Zuhilfenahme der Landes(Wald/Naturschutz)Gesetze oder taggt ausdrücklich ... Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Access-Tags (was: Re: Keine Namen in Mapnik und anderen Karten)
On 02/26/2014 04:38 PM, Martin Koppenhoefer wrote: so oder so sind Krankenfahrstühle wohl nicht berücksichtigt bei diesen beiden Taggingvarianten. http://wiki.openstreetmap.org/wiki/Wheelchair den key für forestry von access zu motor_vehicle finde ich auch OK, das bicycle=yes und ggf. auch das foot=yes würde ich aber drin lassen. Wozu? An einen highway = residential packe ich ja auch nicht überall foot = yes, bicycle = yes dran... Die überwiegende Mehrzahl von Feld- und Forstwegen sind definitiv für Fußgänger und Radfahrer erlaubt. Die in meiner Region so getaggten Wege werden vom Garmin und anderen Navigations-Plattformen auch anstandslos für Fußgänger genutzt. Mein letzter Stand ist, dass die access-Tags für echte *Verbote* verwendet werden sollen. Nur weil jemand der Meinung ist, dass ein Weg nicht mit dem Fahrrad bewältigt werden kann, muss das noch lange nicht Fakt sein. Das kommt nämlich durchaus auch auf das Fahrrad und auf das Können des Fahrers an. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Update JOSM Mappaint Style Coloured Streets 2.0
Hallo, ich habe den JOSM-Style Coloured Streets aktualisiert. Zuerst wollte ich meine Bearbeitung separat bereit stellen, habe dann aber zusammen mit dem ursprünglichen Autor geozeisig entschieden, den Style zu aktualisieren, damit es nicht zuviele verschiedene Styles für den gleichen Zweck gibt. Wer den Style noch nicht kennt, sollte ihn unbedingt einmal ausprobieren. Er erleichtert die Arbeit mit Adressdaten erheblich, indem Straßen, Häuser und Adressnodes mit gleichem Anfangsbuchstabe des Straßennames mit der gleichen Farbe hinterlegt werden. Die wichtigsten Änderungen: - Die Hausnummern sind größer, farbig hinterlegt und dadurch besser sichtbar. - Unterstützung von associatedStreet-Relationen - Unterstützung von Sonderzeichen und unbekannten Zeichen - Gleichzeitige Anzeige von Nummer und Name (und number? bzw. street?, falls notwendig) Außerdem gibt es jetzt eine alternative Version, in der statt des ersten der letzte Buchstabe des Straßennamens ausgewertet wird. Dies ist geeignet für Länder, wo viele Straßen mit dem gleichen Buchstaben beginnen (z.B. in Frankreich Rue ...). Alle weiteren Änderungen und Vergleichsbilder gibt es auf http://josm.openstreetmap.de/wiki/Styles/Coloured_Streetshttp://josm.openstreetmap.de/wiki/Styles/Coloured_Streets#ColouredStreetsdeutsch Ggf. muss der Cache in JOSM für Coloured_Streets gelöscht werden, um das update zu aktivieren. Dazu in den Experten-Einstellungen nach coloured_streets suchen und den Wert vom Schlüssel mirror. http://josm.openstreetmap.de/josmfile?page_Styles/Coloured_Streetsstyle; löschen. VG Klumbumbus ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update JOSM Mappaint Style Coloured Streets 2.0
Hi! Super, danke. Dieser Stil ist wirklich SEHR nützlich für's Adressmappen. Außerdem gibt es jetzt eine alternative Version, in der statt des ersten der letzte Buchstabe des Straßennamens ausgewertet wird. Dies ist geeignet für Länder, wo viele Straßen mit dem gleichen Buchstaben beginnen (z.B. in Frankreich Rue ...). Warum alternative Version und nicht konfigurierbar? Seit einigen Wochen kann man Stil-Farben konfigurierbar machen in JOSM. Das verwende ich im Fahrspur-Stil um verschiedenste Einstellungen konfigurierbar zu machen. Ist zwar nicht hübsch funktioniert aber: bei Optionen bedeutet Weiß - Ja und Schwarz - Nein. Beste Grüße, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update JOSM Mappaint Style Coloured Streets 2.0
On Wed, Feb 26, 2014 at 09:38:39PM +0100, Gertrud Simson wrote: Außerdem gibt es jetzt eine alternative Version, in der statt des ersten der letzte Buchstabe des Straßennamens ausgewertet wird. Dies ist geeignet für Länder, wo viele Straßen mit dem gleichen Buchstaben beginnen (z.B. in Frankreich Rue ...). Ich würde ein MD5 oder aehnlichen Hash verwenden über den Straßennamen und darauf das meinswegen erste Zeichen. Damit ist es egal an welcher stelle des strings eine veränderung eintritt. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wochennotiz Nr. 188 18.2.-24.2.2014
Hallo, die Wochennotiz Nr. 188 mit allen wichtigen Neuigkeiten aus der OpenStreetMap Welt ist da: http://blog.openstreetmap.de/blog/2014/02/wochennotiz-nr-188/ Viel Spaß beim Lesen! ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSM Notes herunterladen
Servus - auch auf die Gefahr hin, dass ich diese Frage wiederhole: Die OpenStreetBugs wurden ja jetzt in 'OSM Notes' konvertiert. Bei OSB gabs die Moeglichkeit, eine Region von Bugs als XML runterzuladen. Das vermisse ich jetzt. Geht das irgendwie? Die Notes sind ja offensichtlich auch nicht Teil der OSM Datenbank, oder? Merci - A. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update JOSM Mappaint Style Coloured Streets 2.0
Am 26. Februar 2014 22:16 schrieb Martin Vonwald imagic@gmail.com: Warum alternative Version und nicht konfigurierbar? Seit einigen Wochen kann man Stil-Farben konfigurierbar machen in JOSM. Das verwende ich im Fahrspur-Stil um verschiedenste Einstellungen konfigurierbar zu machen. Ist zwar nicht hübsch funktioniert aber: bei Optionen bedeutet Weiß - Ja und Schwarz - Nein. Das ist sicher eine Möglichkeit, hatte ich bisher noch nicht bedacht. Die Frage ist nur, ob diese Einstellungen dort dann auch von jedem gefunden und genutzt werden. Aber ich werde mir das mal durch den Kopf gehen lassen. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Notes herunterladen
On 26.02.2014 23:35, Alexander Lehner wrote: Bei OSB gabs die Moeglichkeit, eine Region von Bugs als XML runterzuladen. Das vermisse ich jetzt. Geht das irgendwie? http://wiki.openstreetmap.org/wiki/API_v0.6#Map_Notes_API hth Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Notes herunterladen
On Thu, 27 Feb 2014, malenki wrote: On 26.02.2014 23:35, Alexander Lehner wrote: Bei OSB gabs die Moeglichkeit, eine Region von Bugs als XML runterzuladen. Das vermisse ich jetzt. Geht das irgendwie? http://wiki.openstreetmap.org/wiki/API_v0.6#Map_Notes_API hth Thomas Ja, merci! A. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Access-Tags (was: Re: Keine Namen in Mapnik und anderen Karten)
Am 26. Februar 2014 21:00 schrieb Manuel Reimer manuel.s...@nurfuerspam.de : Die überwiegende Mehrzahl von Feld- und Forstwegen sind definitiv für Fußgänger und Radfahrer erlaubt. und das soll ausreichen als Argument? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Access-Tags (was: Re: Keine Namen in Mapnik und anderen Karten)
Am 27. Februar 2014 02:10 schrieb Martin Koppenhoefer dieterdre...@gmail.com: und das soll ausreichen als Argument? (um die tags zu löschen) ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update JOSM Mappaint Style Coloured Streets 2.0
Ich arbeite auch gerne mit dem Stil in leichter Modifikation für die NRW ALK Rasterdarstellung. http://forum.openstreetmap.org/viewtopic.php?id=23576 Christoph Sent from my iDingens Am 27.02.2014 um 00:04 schrieb Gertrud Simson simson.gert...@gmail.com: Am 26. Februar 2014 22:16 schrieb Martin Vonwald imagic@gmail.com: Warum alternative Version und nicht konfigurierbar? Seit einigen Wochen kann man Stil-Farben konfigurierbar machen in JOSM. Das verwende ich im Fahrspur-Stil um verschiedenste Einstellungen konfigurierbar zu machen. Ist zwar nicht hübsch funktioniert aber: bei Optionen bedeutet Weiß - Ja und Schwarz - Nein. Das ist sicher eine Möglichkeit, hatte ich bisher noch nicht bedacht. Die Frage ist nur, ob diese Einstellungen dort dann auch von jedem gefunden und genutzt werden. Aber ich werde mir das mal durch den Kopf gehen lassen. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Access-Tags (was: Re: Keine Namen in Mapnik und anderen Karten)
Martin Koppenhoefer dieterdreist at gmail.com writes: Die überwiegende Mehrzahl von Feld- und Forstwegen sind definitiv für Fußgänger und Radfahrer erlaubt. und das soll ausreichen als Argument? Wenn die Tags sind meiner Ansicht nach redundant nicht als Argument für eine Löschung der Tags reicht (natürlich nicht im großen Stil sondern nur wenn man den Weg ohnehin anfasst), was dann? Vielleicht habe ich ja auch das Konzept dahinter falsch verstanden. Mein Verständnis von den Access-Tags ist, dass hier vor Ort herrschende Beschränkungen getaggt werden sollen. Im Wiki gibt es zwar gute Beispiele mit Tagging das mir auch logisch erscheint aber kein Wort darüber, dass man für alles, was erlaubt ist, ein Access-Tag setzen muss. Mir geht es um dieses Schild: http://commons.wikimedia.org/wiki/File:Zeichen_260.svg Mit dem Zusatz darunter Land- und forstwirtschaftlicher Verkehr frei. Ich lese da erstmal das motorisierte Fahrzeuge verboten sind. Weiterhin lese ich eine Einschränkung, die forst/landwirschaftlichen Verkehr freigibt. Also motor_vehicle = agricultural. Ich sehe auf dem Schild keinerlei Einschränkungen bezüglich Fußgängern oder Radfahrern. Wenn als ein zusätzliches bicycle = yes und foot = yes erforderlich sein soll, dann müsste da auch horse = yes dran. Auch den Zugang mit Rollschuhen und Inline-Skates verbietet hier niemand. Also noch inline_skates = yes und so weiter... Also eigentlich ein access = yes um alles zu erschlagen. Im Wiki wird von der Kombination access = yes aber abgeraten. Wie ist es also richtig und vollständig wenn man einen Waldweg mit oben genannten Schildern taggen will ohne unnötig viel Tag-Wirrwarr zu produzieren? Gilt bei Access-Tags alles was nicht verboten ist, ist erlaubt oder muss alles was erlaubt ist dran stehen? Wenn letzteres: Muss dann auch an jedem highway = residential die ganze Access-Tag-Flut dranstehen und wenn nein: Warum nicht? Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Access-Tags
Hallo Manuel. Am 27.02.2014 07:58, schrieb Manuel Reimer: Mir geht es um dieses Schild: http://commons.wikimedia.org/wiki/File:Zeichen_260.svg Mit dem Zusatz darunter Land- und forstwirtschaftlicher Verkehr frei. Ich lese da erstmal das motorisierte Fahrzeuge verboten sind. Weiterhin lese ich eine Einschränkung, die forst/landwirschaftlichen Verkehr freigibt. Also motor_vehicle = agricultural. Ich sehe auf dem Schild keinerlei Einschränkungen bezüglich Fußgängern oder Radfahrern. Wenn als ein zusätzliches bicycle = yes und foot = yes erforderlich sein soll, dann müsste da auch horse = yes dran. Auch den Zugang mit Rollschuhen und Inline-Skates verbietet hier niemand. Also noch inline_skates = yes und so weiter... Im Prinzip hast du Recht. Bei den Wegen die explizit beschildert sind, ist es in den üblichen Fällen auch so, dass das echte Wege sind und deine Aussagen treffen zu. (Auch wenn ich Bauchschmerzen hätte, inline_skates auf einem Schotterweg explizit freizugeben.) Aber bei Waldwegen allgemein gelten deine Aussage nicht unbedingt. Z.B. muss ein Waldweg in Ba-Wü mind. 3 Meter breit und befestigt sein, damit man darauf reiten darf. Klar, Wege die das Kriterium nicht erfüllen tragen meistens gar keine Schilder, da sie dann für landwirtschaftliche Fahrzeuge auch eher uninteressant sind. Aber das sieht man den Tags meistens nicht an. Aber es ist utopisch, das jeweils vor Ort zu taggen, da auch ein Mapper diese Gegebenheiten nicht alle auswendig kennt. Bei tracktype=grade3 und schelchter ist es z.B. schwer. Das sind Wege, die meistens nicht beschildert sind, aber zumindest hier dennoch nicht für den fahrenden Verkehr erlaubt sind, da sie nicht (ausreichend) befestigt sind. Das ist auch nicht nur ein kann nicht sondern auch ein darf nicht. Zudem kommt bei Waldwegen ja auch immer der Faktor dazu, dass ein schlecht gepflegter öffentlicher Waldweg und eine Rückegasse im Privatwald sich nicht immer optisch unterscheiden müssen. Beide sind evtl. nicht beschildert aber abseits des Weges darf man mit keinem Fahrzeug durch den Privatwald, auch nicht mit dem Fahrrad. Man kann also manchmal vor Ort nicht erkennen was wirklich die rechtliche Lage ist (und mein Appell wäre dann, das Wild im Zweifel mal in Ruhe schlafen zu lassen). Ich stimme dir also zu, dass man nur das taggen sollte was vor Ort offensichtlich ist, i.d.R. explizit durch Schilder geregelt oder eindeutig bekannt ist. Und tracktype=grade4 und schlechter dienen IMHO eh mehr der Orientierung und nicht einem automatischen Routing. Gruß, Bernd signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-it] http://blackpoint.smaniadisicurezza.it/
Ciao, ho visto questa iniziativa che anche se un po' acerba (manca una'app e i punti sono pochi) mi sembra buona e mi chiedevo se sia possibile chiedere a loro una collaborazione, ad esempio se la licenza se la concede, integrare i blackpoint nei dati osm o in altro modo? Sito Ania http://blackpoint.smaniadisicurezza.it/ Penso proprio che siano stati bravi, ma che una cooperazione con la comunità OSM sia utile ad entrambi e alla sicurezza stradale. Penso ad esempio ad un'app che dia un'allerta all'approssimarsi a un blackpoint. Cosa ne pensate? Ciao, Mirco -- View this message in context: http://gis.19327.n5.nabble.com/http-blackpoint-smaniadisicurezza-it-tp5797521.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] GPX del confine amministrativo
Non funziona mi dice che Error: line 11: static error: Unknown attribute reg in element has-kv. -- View this message in context: http://gis.19327.n5.nabble.com/GPX-del-confine-amministrativo-tp5795396p5797525.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
