[talk-ph] Portable USB for OSM editing
Dear everyone, We created a portable USB flashdisk pre-installed with applications needed for OSM editing. The plan is to give out these sticks during our training/workshops and it should work out-of-the-stick without going through installing everything on each machines. The advantage of this approach over using LiveCDs/VirtualBox is that they can easily bring along the stick anywhere say an internet cafe and continue editing. So far, we were able to run JOSM using the JPortable Launcher. A shortcut would be nice which we plan to work on later. In our test, everything works OK (tested on XP, Win7 32 and 64bits). QGIS seems to be the more difficult to install (will try that later). Please give it a run and send us feedback/bugs. repo: https://github.com/essc/osm_stick/ zipfile (~500MB): https://github.com/essc/osm_stick/archive/master.zip If there are other aplications you think we should add, let me know. -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] Node density visualization
Nice! Node density increase from April 1, 2013 to June 30: http://wiki.openstreetmap.org/wiki/File:Philippines_node_density_increase_from_2013-06-30_to_2013-09-30.pnghttp://wiki.openstreetmap.org/w/images/d/d1/Philippines_node_density_increase_from_2013-04-01_to_2013-06-30.png The above link takes me to an older image. Correct link should be: http://wiki.openstreetmap.org/w/images/4/45/Philippines_node_density_increase_from_2013-06-30_to_2013-09-30.png Some observations: - There is a noticeable rectangle of activity around Metro Manila. I believe this is the waterways project Maning mentioned before: https://lists.openstreetmap.org/pipermail/talk-ph/2013-September/004595.html Yes, and we are not yet finished! -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] Save the Date!
Hello all, Here's the list of apps that have been submitted to the competition: http://philippine-transit.hackathome.com/participating-apps/ From here, 10 will be selected as the finalists and the winners will be awarded on October 14. I've browsed through the apps and several of them make use of OSM: 1. Para - http://philippine-transit.hackathome.com/para/ - A commuter assistance application for Metro Manila, Philippines. Uses OpenStreetMap (OSM), and OpenTripPlanner (OTP) and GTFS data for Metro Manila. 2. Moovit - http://philippine-transit.hackathome.com/moovit/ - I've seen Moovit people editing in OSM in the Philippines (usually adding foot-related tags to major roads in Metro Manila, such as http://www.openstreetmap.org/browse/changeset/17986549) 3. PtA2PtB - http://philippine-transit.hackathome.com/pta2ptb/ - Uses OSM as a base map layer and the Android OSM tool library called OSMDroid 4. PasaHero - http://philippine-transit.hackathome.com/pasahero-2/ - Uses MapQuest Open as the base map layer 5. The Navigator - http://philippine-transit.hackathome.com/the-navigator-2/- Uses OSM as a base map Almost all of the apps are either mobile apps for Android, iOS, or Windows Mobile, or SMS-based applications. Of the web-based apps, I'm most impressed with Sakay.ph - http://sakay.ph/ However it doesn't use any OSM data, and has opted to use Google APIs. But their mapping library is the open-source Leaflet. :) Eugene On Fri, Sep 27, 2013 at 11:46 PM, Holly Krambeck hkramb...@gmail.comwrote: Hey, everyone -- Don't forget to submit your apps for the Philippine Transit App Competition by September 30! (http://philippine-transit.hackathome.com/) Participation has far exceeded expectations during this inaugural competition, and we can't wait to see what everyone comes up with. The awards ceremony will be held in Manila at the University of the Philippines Toyota Auditorium, on *October 14, starting at 5:00 p.m. *Finalists will present their apps in a lightening round -- and they will be trying hard to dazzle you, since the audience vote contributes to their overall score! The event will be followed by a networking reception. Contribute! Come support your friends and colleagues! See where passions about transport have led to innovation in the Philippines :-) See you soon, Holly P.S. If you have any questions about the competition or event, feel free to post questions here or send me an e-mail directly. ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] Save the Date!
Of the web-based apps, I'm most impressed with Sakay.ph - http://sakay.ph/ However it doesn't use any OSM data, and has opted to use Google APIs. But their mapping library is the open-source Leaflet. :) Speaking of Sakay.ph, here's a nice developer's point of view with respect to geocoding in the Philippines: http://pleasantprogrammer.com/posts/geocoding-services.html Basically, the Sakay.ph developer, Philip Cheang, tried both Google's geocoding API and the Nominatim tool for OSM but have not found them satisfactory. So he went with Google's Places API which provided better results. He thinks it would be better to develop an autocompletion software for OSM but given the short time alloted for the competition, he went with Google Places API (which also forces you to use Google Maps tiles). On Fri, Oct 4, 2013 at 8:00 AM, Eugene Alvin Villar sea...@gmail.comwrote: Hello all, Here's the list of apps that have been submitted to the competition: http://philippine-transit.hackathome.com/participating-apps/ From here, 10 will be selected as the finalists and the winners will be awarded on October 14. I've browsed through the apps and several of them make use of OSM: 1. Para - http://philippine-transit.hackathome.com/para/ - A commuter assistance application for Metro Manila, Philippines. Uses OpenStreetMap (OSM), and OpenTripPlanner (OTP) and GTFS data for Metro Manila. 2. Moovit - http://philippine-transit.hackathome.com/moovit/ - I've seen Moovit people editing in OSM in the Philippines (usually adding foot-related tags to major roads in Metro Manila, such as http://www.openstreetmap.org/browse/changeset/17986549) 3. PtA2PtB - http://philippine-transit.hackathome.com/pta2ptb/ - Uses OSM as a base map layer and the Android OSM tool library called OSMDroid 4. PasaHero - http://philippine-transit.hackathome.com/pasahero-2/ - Uses MapQuest Open as the base map layer 5. The Navigator - http://philippine-transit.hackathome.com/the-navigator-2/- Uses OSM as a base map Almost all of the apps are either mobile apps for Android, iOS, or Windows Mobile, or SMS-based applications. Of the web-based apps, I'm most impressed with Sakay.ph - http://sakay.ph/ However it doesn't use any OSM data, and has opted to use Google APIs. But their mapping library is the open-source Leaflet. :) Eugene On Fri, Sep 27, 2013 at 11:46 PM, Holly Krambeck hkramb...@gmail.comwrote: Hey, everyone -- Don't forget to submit your apps for the Philippine Transit App Competition by September 30! (http://philippine-transit.hackathome.com/) Participation has far exceeded expectations during this inaugural competition, and we can't wait to see what everyone comes up with. The awards ceremony will be held in Manila at the University of the Philippines Toyota Auditorium, on *October 14, starting at 5:00 p.m. *Finalists will present their apps in a lightening round -- and they will be trying hard to dazzle you, since the audience vote contributes to their overall score! The event will be followed by a networking reception. Contribute! Come support your friends and colleagues! See where passions about transport have led to innovation in the Philippines :-) See you soon, Holly P.S. If you have any questions about the competition or event, feel free to post questions here or send me an e-mail directly. ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
Re: [OSM-talk-be] fietspad of niet
On Thursday 03 October 2013 05:47:10 Marc Gemis wrote: From the page mentioned by Gilbert, I discovered https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions #Belgium. It states e.g. that the key designated is useless in Belgium: There's no reason for a designated access tag in Belgium as there is no reason why one has more rights over the other on any of these highway types when different vehicle types have access to a road. designated is therefore synonym with yes. Footways could both be signed with a sign that doesn't show a pedestrian at all, and one that does, so basing a designated tag on traffic signs is also flawed. It means that there is no reason for a designated value for access tags (like bicycle=designated), because it doesn't give any special meaning that isn't already included with a simple yes value. The example given is one like this: you could have a way signed with a C3 with an exception for cyclists. Or you could have a sign like this http://wiki.openstreetmap.org/wiki/File:Belgium-trafficsign-C5-C7-C9.svg that prohibits cars, mopeds and motorcycles. There's no real difference for cyclists here, but for one common interpretation of what designated means (it has signs with a picture of that vehicle on it), it would mean that the first one would be bicycle=designated, while the second one wouldn't. But I guess the wording can be a little bit better, this was written when the designated tag was only just being introduced, and one could still look at cycleways with blue round signs as bicycle=designated. Ben ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] fietspad of niet
Groot gelijk. Zo zijn oude tram- of spoorwegen volgens mij fietspaden (cycleway) of er nu een bord staat D7 of C3 (met of zonder onderschrift) of helemaal niets maar met een paal in het midden van de weg. Guy Vanvuchelen -Oorspronkelijk bericht- Van: Wouter Hamelinck [mailto:wouter.hameli...@gmail.com] Verzonden: donderdag 3 oktober 2013 11:40 Aan: OpenStreetMap Belgium Onderwerp: Re: [OSM-talk-be] fietspad of niet Mijn mening over de betreffende weg en dan vooral de highway tag die erbij hoort: - unclassified: prima - track/grade1: ook uitstekend - cycleway: voldoet niet aan de regeltjes. Als in de praktijk dat baantje quasi uitsluitend door fietsers wordt gebruikt is dat echter een prima tag voor mij. Het geeft dan mooi weer wat ik op het terrein kan verwachten. Wat kan mij als ik ga fietsen het exacte juridische status schelen? Met deze mening zal ik hier in de minderheid zijn. Consensus is dat cycleway equivalent is met D7 (rond blauw bord met fiets). Ik ben eerder van het principe If it looks like a duck and it quacks like a duck, then tag it as a duck.. Als iets eruit ziet als een fietspad en het wordt gebruikt als een fietspad, tag het dan als een fietspad. Ik vind dus dat het mogelijk moet zijn om iets als cycleway te taggen zelfs al staat er geen D7. Omgekeerd ken ik een voorbeeld waar een D7 staat, maar geen haar op mijn hoofd denkt eraan om het als cycleway te taggen. Ik herhaal: dit is niet de consensus op de lijst. En ik heb ook niet gezegd dat het baantje uit het voorbeeld geschikt is als cycleway. Daarvoor zou je de situatie ter plaatse moeten kennen en die ken ik niet. - path: zeker niet. Dat is toch geen pad? Ik kan me er aan ergeren dat path als een soort vuilbakcategorie wordt gebruikt voor alles waar je niet met een auto in mag. In sommige streken (bvb rond Lier) zijn alle jaagpaden langs rivieren met highway=path getagd. Dat zorgt ervoor dat path zowel een asfaltvlakte waar je met vier naast elkaar kan fietsen kan zijn, als een smal pad dat in de zomer door brandnetels en bramen overwoekerd wordt en waar je in de winter tot je knieën in de modder staat. Als je dat onderscheid niet kan maken, zijn de data waardeloos voor iemand die te voet of met de fiets is. En dan kan het me echt geen zier schelen of correct getagd is of je daar al dan niet met een skateboard door mag. Just my 2 cents die ik samen met een knuppel in het hoenderhok gooi. wouter 2013/10/2 Glenn Plas gl...@byte-consult.be: inline comments On 2013-10-02 11:07, Stijn Rombauts wrote: Hoi, Met 'tag wat er in het echt staat, niet wat je denkt dat er in het echt zou moeten staan.' en eerdere discussies in het achterhoofd, een volgende vraag. Het gaat over de Sint-Lugardisstraat/Ashoekstraat in Lummen: http://www.openstreetmap.org/#map=16/51.0123/5.1833 Ik ben er van 't weekend met de fiets gepasseerd en ben volgend bord tegengekomen: https://maps.google.be/maps?q=lummenhl=nlll=51.018767,5.185422spn=0 .023082,0.066047sll=51.09623,4.227975sspn=1.474765,4.22699hnear=Lum men,+Limburg,+Vlaams+Gewestt=mz=15layer=ccbll=51.018767,5.185422p anoid=cQzua7yIjaXjz-4IfM7JCwcbp=12,222.63,,0,9.65 Dus: verboden toegang voor iedere bestuurder uitgezonderd fietsers (en bromfietsen A) en uitgezonderd landbouwgebruik. Weg was gekarteerd door RoRay als fietspad (highway = cycleway). Ik maak daarvan highway = track; tracktype = grade1 (want verharde weg); motor_vehicle = agricultural highway=track tracktype=grade1 traffic_sign=BE:C3 access=designated motor_vehicle=agricultural RoRay heeft er nu terug highway = cycleway met motor_verhicle = permissive van gemaakt. Dit is verkeerd. Wat zijn de correcte tags? Ik moet wel toegeven dat ik zelf bij de name-tag in de mist ben gegaan, wat door RoRay rechtgezet is. Kan zijn ,maar zijn definitie is verkeerd. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be -- Den som ikke tror på seg selv kommer ingen vei. - Thor Heyerdahl ___ 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
Re: [OSM-talk-be] fietspad of niet
On Thursday 03 October 2013 12:53:20 Guy Vanvuchelen wrote: Groot gelijk. Zo zijn oude tram- of spoorwegen volgens mij fietspaden (cycleway) of er nu een bord staat D7 of C3 (met of zonder onderschrift) of helemaal niets maar met een paal in het midden van de weg. 't is één ding van dat te vinden, en ik respecteer die mening. Maar er wordt nooit een alternatief voorzien voor wat de regels vandaag de dag juist betekenen: namelijk dat ze vertellen wat wel en niet is toegelaten op welke weg. Je moet niet blindstaren op highway=cycleway, maar het in het hele plaatje bekijken en met een oplossing komen voor elk soort pad en weg dat er bestaat. En een regel die elke subjectiviteit uitsluit om later geen discussies te hebben of nu iets wel of niet meer geschikt is voor het één of het ander. Case in point: het gaat quasi altijd over fietspaden en fietswegen. Hoe zit het bijvoorbeeld met oude spoorwegpaden waar ruiters toegelaten zijn. highway=cycleway of highway=bridleway? Is dat pad in het park waar wel fietsers mogen rijden maar niet echt supergeschikt is nu meer een highway=footway of highway=cycleway? Een bos met allemaal zandpaden, wordt goed gebruikt door fietsers, welke highway krijgt dat? Het is ook een beetje gek dat altijd wel gedacht wordt aan de fietsers, maar nooit aan bromfietsers en ruiters waardoor die informatie daarover bijna nooit wordt gemapt, of toch alleszins geen rekening mee gehouden. Laat een highway=cycleway bijvoorbeeld bromfietsers toe? Zoja, kan je meteen een hoop oude spoorwegbermen terug aflopen om die restrictie erbij te zetten. Zoniet, dan liggen er ook heel veel fietspaden in OSM waar je de bromfietsers expliciet zal moeten toelaten. Zodus, vooraleer je zegt: ik vind dat iets zo moet zijn want maakt mooiere kaartjes of wat dan ook, denk aan het effect dat dat heeft en kom met oplossingen als je de hele manier van mappen wil omdraaien. Overigens is de hele discussie over highway=path/cycleway/footway/... vaak enkel een discussie vanwege de kaartjes die gerenderd worden omdat dat nu het zichtbaarste is. De niet meer bestaande osmarender was iets slimmer en een pad met bijvoorbeeld highway=path + vehicle=no + bicycle=yes werd net hetzelfde gerenderd als een highway=cycleway. Moest mapnik dat ook doen was er voor vele mensen niet echt een probleem denk ik. Ben ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] fietspad of niet
Hebben jullie als eens gekeken op openfietsmap.nl, naar de legenda ? Daar wordt een highway=bicycle + tracktype=grade4/5 gelijkgesteld aan een pad, terwijl een highway=bicycle met een betere onderlaag iets anders is en ook bij uitzoomen nog zichtbaar is. voor de rest sluit ik me aan bij wat Ben schreef. Er zijn in de buurt een aantal jaagpaden die ook door bewoners mogen gebruikt worden. highway=cycleway + motor_vehicle=destination is ook een beetje vreemd, niet ? Je zou ze bijna als highway=unclassified moeten taggen omdat er enkele zijn waarop dus die access=destination geldig is. En dan via de nodige beperkingen in vele gevallen enkel fietsers, voetgangers en diensten overhouden. groeten m 2013/10/3 Ben Laenen benlae...@gmail.com: On Thursday 03 October 2013 12:53:20 Guy Vanvuchelen wrote: Groot gelijk. Zo zijn oude tram- of spoorwegen volgens mij fietspaden (cycleway) of er nu een bord staat D7 of C3 (met of zonder onderschrift) of helemaal niets maar met een paal in het midden van de weg. 't is één ding van dat te vinden, en ik respecteer die mening. Maar er wordt nooit een alternatief voorzien voor wat de regels vandaag de dag juist betekenen: namelijk dat ze vertellen wat wel en niet is toegelaten op welke weg. Je moet niet blindstaren op highway=cycleway, maar het in het hele plaatje bekijken en met een oplossing komen voor elk soort pad en weg dat er bestaat. En een regel die elke subjectiviteit uitsluit om later geen discussies te hebben of nu iets wel of niet meer geschikt is voor het één of het ander. Case in point: het gaat quasi altijd over fietspaden en fietswegen. Hoe zit het bijvoorbeeld met oude spoorwegpaden waar ruiters toegelaten zijn. highway=cycleway of highway=bridleway? Is dat pad in het park waar wel fietsers mogen rijden maar niet echt supergeschikt is nu meer een highway=footway of highway=cycleway? Een bos met allemaal zandpaden, wordt goed gebruikt door fietsers, welke highway krijgt dat? Het is ook een beetje gek dat altijd wel gedacht wordt aan de fietsers, maar nooit aan bromfietsers en ruiters waardoor die informatie daarover bijna nooit wordt gemapt, of toch alleszins geen rekening mee gehouden. Laat een highway=cycleway bijvoorbeeld bromfietsers toe? Zoja, kan je meteen een hoop oude spoorwegbermen terug aflopen om die restrictie erbij te zetten. Zoniet, dan liggen er ook heel veel fietspaden in OSM waar je de bromfietsers expliciet zal moeten toelaten. Zodus, vooraleer je zegt: ik vind dat iets zo moet zijn want maakt mooiere kaartjes of wat dan ook, denk aan het effect dat dat heeft en kom met oplossingen als je de hele manier van mappen wil omdraaien. Overigens is de hele discussie over highway=path/cycleway/footway/... vaak enkel een discussie vanwege de kaartjes die gerenderd worden omdat dat nu het zichtbaarste is. De niet meer bestaande osmarender was iets slimmer en een pad met bijvoorbeeld highway=path + vehicle=no + bicycle=yes werd net hetzelfde gerenderd als een highway=cycleway. Moest mapnik dat ook doen was er voor vele mensen niet echt een probleem denk ik. Ben ___ 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
Re: [OSM-talk-be] toegangsbeperkingen
On Thursday 03 October 2013 13:53:16 Marc Gemis wrote: hoe tag je Uitgezonderd diensten Uitgezonderd aangelanden Uitgezonderd bewoners Die laatste lijkt me strenger dan access=destination. Ik weet ook niet hoe die mensen daar ooit een verhuiswagen of zo voor hun deur kunnen krijgen. Bestaan nog geen steeds tags voor voor zover ik weet. Heb het ooit wel eens erover gehad over enkele van die beperkingen en welke tags ervoor gebruikt moeten worden, maar vraag me nu niet waar dat ergens was :-) Verschil tussen aangelanden/riverains en bewoners/résidents is ook vrij klein (en met plaatselijk verkeer/plaatselijke bediening erbij) en ik herinner me nog eens een discussie om uit te leggen dat dit niet allemaal zomaar access=destination is. Misschien nog eens een poging wagen op de internationale tagging mailing list? Voor bewoners zou ik residential=yes gebruiken. Maar de rest? Overigens zijn er nog wel meer van dat die je kan tegen komen: marktvoertuigen, ceremoniewagens, bezoekers, vergunninghouders... En ze kunnen soms heel specifiek worden... Dan wordt de vraag ook hoe ver je daarin moet gaan. Ben ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] toegangsbeperkingen
Ben, bedankt voor je antwoord Ik denk dat het belangrijkste kenmerk moet zijn dat een router je er niet moet laten langsrijden om naar de volgende straat te gaan. Daarvoor is access=destination natuurlijk voldoende. Als je echt in die straat moet zijn, met bv. een vrachtwagen ga je die borden toch negeren vermoed ik. Of op de hoek stoppen. Dus het sop is de kool misschien niet waard. Ik zal het voorlopig bij access=destination + note=access=residents of zo houden m. 2013/10/3 Ben Laenen benlae...@gmail.com: On Thursday 03 October 2013 13:53:16 Marc Gemis wrote: hoe tag je Uitgezonderd diensten Uitgezonderd aangelanden Uitgezonderd bewoners Die laatste lijkt me strenger dan access=destination. Ik weet ook niet hoe die mensen daar ooit een verhuiswagen of zo voor hun deur kunnen krijgen. Bestaan nog geen steeds tags voor voor zover ik weet. Heb het ooit wel eens erover gehad over enkele van die beperkingen en welke tags ervoor gebruikt moeten worden, maar vraag me nu niet waar dat ergens was :-) Verschil tussen aangelanden/riverains en bewoners/résidents is ook vrij klein (en met plaatselijk verkeer/plaatselijke bediening erbij) en ik herinner me nog eens een discussie om uit te leggen dat dit niet allemaal zomaar access=destination is. Misschien nog eens een poging wagen op de internationale tagging mailing list? Voor bewoners zou ik residential=yes gebruiken. Maar de rest? Overigens zijn er nog wel meer van dat die je kan tegen komen: marktvoertuigen, ceremoniewagens, bezoekers, vergunninghouders... En ze kunnen soms heel specifiek worden... Dan wordt de vraag ook hoe ver je daarin moet gaan. Ben ___ 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
Re: [OSM-legal-talk] About CC-4.0 and ODbl
On 02/10/13 18:59, Rob Myers wrote: On 01/10/13 03:48 AM, Jonathan Harley wrote: On 01/10/13 06:01, Stephan Knauss wrote: On 01.10.2013 06:28, Pekka Sarkola wrote: Questions: Is CC-BY-4.0 compatible with OSM current license (ODbl)? If data is released under CC-BY-4.0: can we import it to OSM? To my understanding not even ODbL would be suitable for import into OSM. To be suitable for OSM it must conform with the contributor terms which allow a future license change. That applies to data added by individual contributors, but the OSMF can allow imports under other terms. See the preamble to http://www.osmfoundation.org/wiki/License/Contributor_Terms I imagine there would probably be no clash with our principles in the case of CC-BY so long as the copyright owner was happy with our system for attribution. BY-SA 4.0 looks like it clashes with the ODbl due to its coverage of Copyright-like Rights. Agreed. CC-BY is probably compatible but CC-BY-SA definitely isn't as it restricts the license for produced works more than ODbL does (to ones that are like BY-SA). Is it possible to have a BY-SA 4.0 Produced Work? It's possible to give a produced work derived from OSM any license you like (if that's what you mean?) so long as it retains OSM's attribution. Including all rights reserved. Which is exactly why BY-SA data can't be imported or used in OSM. HTH, Jonathan -- Dr Jonathan Harley :Managing Director: SpiffyMap Ltd m...@spiffymap.com Phone: 0845 313 8457 www.spiffymap.com The Venture Centre, Sir William Lyons Road, Coventry CV4 7EZ, UK ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] About CC-4.0 and ODbl
On 03/10/13 04:32 AM, Jonathan Harley wrote: On 02/10/13 18:59, Rob Myers wrote: Is it possible to have a BY-SA 4.0 Produced Work? It's possible to give a produced work derived from OSM any license you like (if that's what you mean?) so long as it retains OSM's attribution. Including all rights reserved. But doesn't BY-SA claim to cover the database rights? Doesn't that clash with the ODbL? ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] Administrative boundaries export
Am 02/ott/2013 um 23:52 schrieb Christian Quest cqu...@openstreetmap.fr: UK level 4 is on the maritime borders (island culture ?) where most other European countries stop on the coastline... tagging bio-diversity is not helpful ! well, maybe this is how things are correct? years ago I stumbled upon Liberia having a 200NM maritime border. Checking with other sources it turned out that they indeed claim this area. Looking now at the osm map someone has normalized the coastline leaving them the same maritime border than the rest, and it looks better but I'm not sure it also is more correct. The world is divers and the map should represent how things are, even if this seems more chaotic than nicely structured. cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Administrative boundaries export
Well, I think I fully understand all the diversity, but when you want the shape of UK or Liberia, I presume most people expect the land, not the maritime boundaries claimed ones or whatever. This does not prevent to have 2 boundary relations, one for land boundary and one including maritime ones (that's the case for France for example + one including overseas land), but make sure the tagging is homogeneous worldwide as far as possible to allow easy reuse of data. I've been asked too about all maritime boundaries of the world... I tried to extract that but it was too inconsistent to be useable. 2013/10/3 Martin Koppenhoefer dieterdre...@gmail.com Am 02/ott/2013 um 23:52 schrieb Christian Quest cqu...@openstreetmap.fr : UK level 4 is on the maritime borders (island culture ?) where most other European countries stop on the coastline... tagging bio-diversity is not helpful ! well, maybe this is how things are correct? years ago I stumbled upon Liberia having a 200NM maritime border. Checking with other sources it turned out that they indeed claim this area. Looking now at the osm map someone has normalized the coastline leaving them the same maritime border than the rest, and it looks better but I'm not sure it also is more correct. The world is divers and the map should represent how things are, even if this seems more chaotic than nicely structured. cheers, Martin -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Administrative boundaries export
Thanks for all the advises and suggestion. I agree that in order to achieve this, at least 2 tables/trees/dbs have to be maintained: 1 - The relationship of each admin_boundary on a certain level with its parent (and the opposite) and whether this same boundaries applies for other admin_boundaries (as suggested for some areas of Germany) 2 - For each country, how to distinguish the land mass from territorial waters. I am more interested on mapping the land mass, but the territorial waters could be also generated if we have this distinction. Regarding 1, I think it would be reasonable to try to codify it within OSM (for instance using is_in tag), but I think the tagging scheme should be further developed to correctly capture all the information we need, so I will generate an external table/database instead. Probably, a table per admin_level containing relation-id, ISO 3166 code would be enough (but I have to study what should be used for deeper subdivision levels), as it will contain the father-children relationships and also would solve the problem with a boundary being the same for different admin_levels. The algorithm could check against OSM data for code and for relation-id when missing, and report any added or removed boundaries compared with previous version. Regarding 2, for the long term I thing separate relationships should be present in OSM for land mass and territorial waters (this also involves clarifying the tagging scheme), but for the moment I will try to manage with existing tags. I assume it will not be a small task, so I will try to be pragmatic and start exporting what can be exported using a straightforward way and then refining the approach little by little. Probably, in order to refine these approaches it would be helpful to have some viewer similar to the one on openstreetmap.fr (to easily see what should be corrected on OSM data or on the extraction algorithms), but for the moment this is outside of my plans. I expect results on the scale of months/years rather than days/weeks (according to my planned dedication), but I will keep you informed when I get some news. Eugene, I am also interested on your proposal to store on Wikidata a table/database similar to the one described on 1, so any further details on available infrastructure, technologies in use, work already done, etc are welcome. Cheers, César Martínez Izquierdo 2013/10/3 Eugene Alvin Villar sea...@gmail.com On Thu, Oct 3, 2013 at 6:52 AM, Christian Quest cqu...@openstreetmap.frwrote: UK level 4 is on the maritime borders (island culture ?) where most other European countries stop on the coastline... tagging bio-diversity is not helpful ! This is actually another point to consider when extracting admin boundaries from OSM data. My personal view is that the admin boundary marks the boundary where the administrative entity exercises jurisdiction. Under UNCLOS, nations are allowed to exercise full sovereignty over internal waters (which includes water seaward of the coastline but within the baselines) and almost full sovereignty (foreign ships are allowed innocent passage) for territorial waters (up to 12 nautical miles from the baselines). So I think that using the maritime boundaries as the admin_level=2 boundary is not incorrect and this is reflected in OSM. Use of maritime boundaries for admin_level=3 and higher (such as with UK) depends on how the particular nation interprets its internal maritime/fisheries laws. In my country, we have municipal waters which can be up to 15 kilometers from the shoreline and that's where municipalities can exercise jurisdiction. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - César Martínez Izquierdo GIS developer - - - - - - - - - - - - - - - - - - - - ETC-SIA: http://sia.eionet.europa.eu/ Universitat Autònoma de Barcelona (SPAIN) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Administrative boundaries export
2013/10/3 César Martínez Izquierdo cesar@gmail.com 2 - For each country, how to distinguish the land mass from territorial waters. I am more interested on mapping the land mass, but the territorial waters could be also generated if we have this distinction. no, the landmass is the land inside the territorial waters, but the territorial waters are not the extension of the coastline by 12seamiles but the extension of the baseline. We generally do not have the baselines in OSM as far as I am aware of. cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Administrative boundaries export
2013/10/3 Christian Quest cqu...@openstreetmap.fr Well, I think I fully understand all the diversity, but when you want the shape of UK or Liberia, I presume most people expect the land, not the maritime boundaries claimed ones or whatever. yes, but you don't need a special relation for this, you only have to find out the coastlines inside the territory (and where they cross the national borders so you can find out the land borders to other countries). This does not prevent to have 2 boundary relations, one for land boundary and one including maritime ones you don't need them, and you will put unneccessary heavy load on the db creating a relation with all coastlines and the land side borders in it (as the coastlines are much more detailed than the baseline). In the end, that's the reason we do coastlines with shapefiles and not with huge polygons. We used to have a landmass relation for Italy as well, because some well meaning mappers have created them for us, but it was continuously broken and augmented the complexity for coastline edits with an unneccessary complication. It grew in short time to 928 versions, so after a discussion on talk-it, and with nobody needing it, we decided to delete it some weeks ago: http://www.openstreetmap.org/browse/relation/957374 (that's the case for France for example + one including overseas land), but make sure the tagging is homogeneous worldwide as far as possible to allow easy reuse of data. My suggestion would be to delete the French landmass relation as well for homogenisation ;-) cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Administrative boundaries export
Hi Frederik, regarding software, I am already familiar with Mapit scripts code, which are able to extract admin boundary polygons for each level (it is not creating relationships though). How do you see Nominatim or Osmium/osmjs better for the purpose? Reading osmjs documentation, I see it could be used to build a similar script to mapit one (which uses a local instance of OSM3S api). Do you think it would be faster? I envisage 2 possible approaches: - using one of these tools to do a first export, which should be later processed by a separate script in order to make sense on the particularities of each country. - creating an export script from scratch (similar to or based on Mapit scripts) that select the right relations and tags for each country. It should be faster but probably more costly to implement I will probably try the first option, but I expect that any of them would be costly to maintain if there are frequent changes of the tagging scheme for each country. (But nobody said it would be an easy task :-) Cheers, César 2013/10/2 Frederik Ramm frede...@remote.org Hi, On 02.10.2013 18:23, César Martínez Izquierdo wrote: I plan to create and make easily available a world-wide administrative layer based on OSM data, ideally including existing administrative codes (ISO, NUTS in Europe, etc) for each level and producing regular updates (for instance once a year). This is something I have been thinking about for a long time (but never written any usable code). Nominatim is probably a good starting point - a better one than MapIt I should think. If you're only after extracting certain relation polygons then you could as well use osmjs (part of Osmium) and have it generate shape files for you, or adapt the shapefile/ogr export samples in Osmium; this will not yet give you a hierarchy, only individual boundaries, and you have to find out the hierarchy yourself. Finding out the hierarchy is going to be tricky. Nominatim does go to some lengths to do that already. It sounds easy (find all polygons with an admin level smaller than X where this polygon I'm looking at lies in). But in reality you will encounter at least: * missing polygons on all levels - sometimes simply not mapped, sometimes missing by design, e.g. Germany has some areas where admin levels 8, 6, and 4 coincide, these are mapped as admin_level 4, so draw a map of all admin_level 8 areas in Germany and you have lots of holes in them * broken polygons on all levels; brokenness changes by the day, i.e. what is working today may be broken tomorrow and vice versa * occasionally (e.g. Japan) linear regional boundaries that simply go from coast to coast without including the coastline * occasionally (e.g. Chile) a regional boundary that is not a multipolygon relation but instead a grouping of smaller regional entities * sometimes small geometric inaccuracies mean that e.g. a state boundary fails the is-in test for the country boundary because there's just a little square metre somewhere that is mapped as belonging to the state but not the country * overlapping admin polygons of the same admin level I think that ate the very least you need to run the evaluation regularly and compare: Do I have new polygons this week - have others vanished, and if so, is that because they were explicitly deleted/replaced, or were they just accidentally broken and I should continue to use last week's? What we would really need though, is something much bigger: A separate database of admin hierarchies, where people could - in a crowdsourced manner - record things like: There is an adminlevel 2 entities called Germany It is divided into 16 exclusive adminlevel 4 entities with the following names: ... These 16 entities cover the area of Germany completely (no holes or sea areas that would be outside of one of the entities) The adminlevel 4 entity named 'Brandenburg' is divided in X adminlevel 6 entities... and so on. A tree of arbitrary size where people can add and edit at will. Now you will say but this tree could be generated from OpenStreetMap, and I grant that one could attempt to build such a tree but it will always be faulty and reflect the current brokenness of geometries in OSM. One could *start* with an OSM-generated tree, but after that, the tree must be kept separate. People should be able to add stuff to the tree even when it is not in OpenStreetMap - there should be an adminlevel 8 boundary called so-and-so. A regularly-running process would then compare the tree to OpenStreetMap, and generate error reports that can be presented visually: The tree says that there should be a region called X in Germany but OSM doesn't have one. There is an area here that is not covered by any adminlevel 4 area but the tree says that taken together the adminlevel 4 areas must cover all of the country. The tree claims there should be a region called X but in OSM there's only a region
Re: [OSM-talk] Administrative boundaries export
Hi, On 10/03/13 12:32, César Martínez Izquierdo wrote: Hi Frederik, regarding software, I am already familiar with Mapit scripts code, which are able to extract admin boundary polygons for each level (it is not creating relationships though). How do you see Nominatim or Osmium/osmjs better for the purpose? Reading osmjs documentation, I see it could be used to build a similar script to mapit one (which uses a local instance of OSM3S api). Do you think it would be faster? I would think so. The Mapit stack is very convoluted - as far as I remember, it first extracts stuff from a planet file with Osmosis, then imports that into osm3s (aka overpass), then makes queries from there. This is a very complicated way to do it - with an osmjs/osmium based program you'd process the planet once and that's it (if using OGR output like in the osmium_toogr example you can even generate KML directly), and the time spend would very likely be much less than even the initial Osmosis step of the Mapit stack. I'd assume it would take a couple hours for a full export. Of course if you're already familiar with the Mapit stack and it works for you, that's fine too. - using one of these tools to do a first export, which should be later processed by a separate script in order to make sense on the particularities of each country. Yes, I think that makes sense, however keep in mind that depending on how you do the export, some things might already be broken at that stage, and no chance for a program down the line to fix it. The export process would probably have to be modified to export a collection of broken things in addition to the working things, so that a script down the line can then do something with the broken things. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Administrative boundaries export
On Thu, Oct 03, 2013 at 12:32:36PM +0200, César Martínez Izquierdo wrote: Hi Frederik, regarding software, I am already familiar with Mapit scripts code, which are able to extract admin boundary polygons for each level (it is not creating relationships though). How do you see Nominatim or Osmium/osmjs better for the purpose? Nominatim already does a lot of the stuff you are planning to do. It creates geometries for admin boundaries from OSM data and puts them in a proper hierarchy. It is able to process updates and in the process makes sure that boundaries do not just disappear if somebody breaks the relation. If you only process the data that interests you (boundary=administrative and place nodes) it is not even that resource-hungry. It does have support for listing broken boundaries [1] and during the last hack day Brian has written a proof-of-concept for browsing admin hierarchies[2]. There is even a script to dump objects within a certain boundary[3] which could be easily extended to dump entire hierarchies. All these functions should currently be used with care though. There are known bugs and the output needs to be improved to make them really usable. Basically, most of the work to do would be on the output side, the heavy lifting of processing the data is already done. Well, apart from checking the OSM boundaries against reality. But I think wiki data is a good starting point for that. I will probably try the first option, but I expect that any of them would be costly to maintain if there are frequent changes of the tagging scheme for each country. (But nobody said it would be an easy task :-) Making boundary tagging more visible will hopefully help to stablize and unify the tagging schemas. The less country-specific exceptions the better. Sarah [1] http://nominatim.osm.org/polygons [2] http://nominatim.openstreetmap.org/hierarchy.php?place_id=97944985 (This is for demonstration only, please do not scrape. It will not always give you the expected results anyways because there is a known bug with parenting which still lingers in the DB.) [3] https://github.com/lonvia/Nominatim/blob/export-script/utils/export.php 2013/10/2 Frederik Ramm frede...@remote.org Hi, On 02.10.2013 18:23, César Martínez Izquierdo wrote: I plan to create and make easily available a world-wide administrative layer based on OSM data, ideally including existing administrative codes (ISO, NUTS in Europe, etc) for each level and producing regular updates (for instance once a year). This is something I have been thinking about for a long time (but never written any usable code). Nominatim is probably a good starting point - a better one than MapIt I should think. If you're only after extracting certain relation polygons then you could as well use osmjs (part of Osmium) and have it generate shape files for you, or adapt the shapefile/ogr export samples in Osmium; this will not yet give you a hierarchy, only individual boundaries, and you have to find out the hierarchy yourself. Finding out the hierarchy is going to be tricky. Nominatim does go to some lengths to do that already. It sounds easy (find all polygons with an admin level smaller than X where this polygon I'm looking at lies in). But in reality you will encounter at least: * missing polygons on all levels - sometimes simply not mapped, sometimes missing by design, e.g. Germany has some areas where admin levels 8, 6, and 4 coincide, these are mapped as admin_level 4, so draw a map of all admin_level 8 areas in Germany and you have lots of holes in them * broken polygons on all levels; brokenness changes by the day, i.e. what is working today may be broken tomorrow and vice versa * occasionally (e.g. Japan) linear regional boundaries that simply go from coast to coast without including the coastline * occasionally (e.g. Chile) a regional boundary that is not a multipolygon relation but instead a grouping of smaller regional entities * sometimes small geometric inaccuracies mean that e.g. a state boundary fails the is-in test for the country boundary because there's just a little square metre somewhere that is mapped as belonging to the state but not the country * overlapping admin polygons of the same admin level I think that ate the very least you need to run the evaluation regularly and compare: Do I have new polygons this week - have others vanished, and if so, is that because they were explicitly deleted/replaced, or were they just accidentally broken and I should continue to use last week's? What we would really need though, is something much bigger: A separate database of admin hierarchies, where people could - in a crowdsourced manner - record things like: There is an adminlevel 2 entities called Germany It is divided into 16 exclusive adminlevel 4 entities with the following
Re: [OSM-talk] Administrative boundaries export
From: Martin Koppenhoefer [mailto:dieterdre...@gmail.com] Sent: Thursday, October 03, 2013 3:20 AM Subject: Re: [OSM-talk] Administrative boundaries export you don't need them, and you will put unneccessary heavy load on the db creating a relation with all coastlines and the land side borders in it (as the coastlines are much more detailed than the baseline). Expanding on this, there are some large boundary relations which have all the coastline for an admin_level region and have over 10 000 members. These are frankly harmful and impossible to work with. When I redid the Alaska boundaries, I put them at 3 miles out I believe. Frankly, I find the idea of using the coastline as an admin boundary rather silly. This would mean that if you step out 1 foot into the water, you've left the state or country. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Administrative boundaries export
2013/10/3 Paul Norman penor...@mac.com Frankly, I find the idea of using the coastline as an admin boundary rather silly. This would mean that if you step out 1 foot into the water, you've left the state or country. indeed it seems to be different: en.wikipedia.org/wiki/Territorial_waters look at the internal waters in the diagram, those allow to reduce the admin-ways a lot by simplifying and not using the coastline. cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Administrative boundaries export
On Thu, Oct 3, 2013 at 9:18 PM, Martin Koppenhoefer dieterdre...@gmail.comwrote: 2013/10/3 Paul Norman penor...@mac.com Frankly, I find the idea of using the coastline as an admin boundary rather silly. This would mean that if you step out 1 foot into the water, you've left the state or country. indeed it seems to be different: en.wikipedia.org/wiki/Territorial_waters look at the internal waters in the diagram, those allow to reduce the admin-ways a lot by simplifying and not using the coastline. Not quite. By default the baselines use the mean low-water line, basically the coastlines, but not the coastlines in the OSM sense (high-water line). Straight baselines *may* be used only in cases where the coastline is deeply indented such as bays, coves, fjords, and the like, or if the state claims to be an archipelagic state (whose baselines are all straight). So for the more-or-less concave coastlines, the baselines would still be complex. See: https://en.wikipedia.org/wiki/Baseline_%28sea%29 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Administrative boundaries export
On Thu, Oct 3, 2013 at 6:35 PM, César Martínez Izquierdo cesar@gmail.com wrote: Eugene, I am also interested on your proposal to store on Wikidata a table/database similar to the one described on 1, so any further details on available infrastructure, technologies in use, work already done, etc are welcome. Hi César, you can look at this Wikidata page for the German state of Baden-Württemberg as an example: https://www.wikidata.org/wiki/Q985 It currently contains interesting properties and relationships that may be what we need. Some interesting properties/relations are (especially the OSM one): country=Germany capital=Stuttgart type of administrative division=state of Germany ISO 3166-2=DE-BW GND identifier=4004176-1 contains administrative division=Regierungsbezirk Freiburg, Regierungsbezirk Karlsruhe, Regierungsbezirk Stuttgart, Regierungsbezirk Tübingen is in the administrative unit=Germany OpenStreetMap Relation ID=62611 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Administrative boundaries export
On Thu, Oct 3, 2013 at 2:16 PM, Paul Norman penor...@mac.com wrote: Frankly, I find the idea of using the coastline as an admin boundary rather silly. This would mean that if you step out 1 foot into the water, you've left the state or country. All the states or countries maps I've seen in my life used the coastline. It does not mean that the sovereignty stops at the water line. It's just a convention. Pieren ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Administrative boundaries export
2013/10/3 Pieren pier...@gmail.com All the states or countries maps I've seen in my life used the coastline. It does not mean that the sovereignty stops at the water line. It's just a convention. how many states or country maps have you seen in scale 1:1000? cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Administrative boundaries export
2013/10/3 Martin Koppenhoefer dieterdre...@gmail.com well, maybe this is how things are correct? years ago I stumbled upon Liberia having a 200NM maritime border. in reference to this I have found a document today stating that the president of Liberia has released an executive order on Jan 10th 2013 which seems to reduce their respective claims to the standard: http://emansion.gov.lr/doc/Executive_Order_No._48.pdf cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Administrative boundaries export
On 2013-10-03 14:53, Martin Koppenhoefer wrote: 2013/10/3 Pieren pier...@gmail.com All the states or countries maps I've seen in my life used the coastline. It does not mean that the sovereignty stops at the water line. It's just a convention. how many states or country maps have you seen in scale 1:1000? All maps I have seen make a clear distinction between land and sea. Only a very small number of maps I've seen actually show borders on international waters. So it all depends on what you want to show and how you visualise it. If you make a map of Germany or the Netherlands with one color within the borders in the sense of territorial waters, I think few people would recognise them. For the netherlands, you would have a smooth coastline without islands (Zeeland and Waddeneilanden). Regards, Maarten ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Administrative boundaries export
The important issue here is that there is lots of potential uses here (layers are not used exclusively for creating maps, they can also be used for analysis) and there are people wishing to use these datasets: the administrative boundaries based on coastline (call them whatever you want), the ones based on the territorial waters, and possible others. Because of this reason, it would be useful to have them explicitly mapped on OSM. It is not the same to just extract a relation and descendants and build some polygons from there, than to extract the coastline and the borders that are not coastline and try to see how they fit within their containing country. It is feasible, but not practical. However, as you suggested, it is important to keep an eye on maintainability of OSM data when creating these relations. A simple approach would be to create land mass relations having other relations as members. For instance, in Spain such relationship could be easily created from the admin_level=4 relations, containing just 19 members (as subareas). As far as the admin_level=4 relations are correct, the superrelation should be correct (if not, they should be corrected anyway). I don't know if such approach would be so feasible for other countries. Of course, proper tagging should be applied to these relations in order to don't create ambiguities. César 2013/10/3 Martin Koppenhoefer dieterdre...@gmail.com 2013/10/3 Pieren pier...@gmail.com All the states or countries maps I've seen in my life used the coastline. It does not mean that the sovereignty stops at the water line. It's just a convention. how many states or country maps have you seen in scale 1:1000? cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - César Martínez Izquierdo GIS developer - - - - - - - - - - - - - - - - - - - - ETC-SIA: http://sia.eionet.europa.eu/ Universitat Autònoma de Barcelona (SPAIN) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Administrative boundaries export
That sounds interesting. I am not familiar with Nominatim, but I have correctly understood, the result is a Postgres/postgis database with all those polygons and hierarchies. This could be an interesting approach as the post-processing could be directly done there using PostGIS predicates. However, I am not sure about the generated hierarchies, as they don't keep all OSM admin_levels into account (at least in the nomenclature: country, state, county) and I see clear errors for Spain using the link [2] that you provided. It would be interesting to know how these hierarchies are generated (just OSM tags and geometric relations, external database, etc). In any case, it seems a good starting point for my project. Cheers, Cesar 2013/10/3 Sarah Hoffmann lon...@denofr.de On Thu, Oct 03, 2013 at 12:32:36PM +0200, César Martínez Izquierdo wrote: Hi Frederik, regarding software, I am already familiar with Mapit scripts code, which are able to extract admin boundary polygons for each level (it is not creating relationships though). How do you see Nominatim or Osmium/osmjs better for the purpose? Nominatim already does a lot of the stuff you are planning to do. It creates geometries for admin boundaries from OSM data and puts them in a proper hierarchy. It is able to process updates and in the process makes sure that boundaries do not just disappear if somebody breaks the relation. If you only process the data that interests you (boundary=administrative and place nodes) it is not even that resource-hungry. It does have support for listing broken boundaries [1] and during the last hack day Brian has written a proof-of-concept for browsing admin hierarchies[2]. There is even a script to dump objects within a certain boundary[3] which could be easily extended to dump entire hierarchies. All these functions should currently be used with care though. There are known bugs and the output needs to be improved to make them really usable. Basically, most of the work to do would be on the output side, the heavy lifting of processing the data is already done. Well, apart from checking the OSM boundaries against reality. But I think wiki data is a good starting point for that. I will probably try the first option, but I expect that any of them would be costly to maintain if there are frequent changes of the tagging scheme for each country. (But nobody said it would be an easy task :-) Making boundary tagging more visible will hopefully help to stablize and unify the tagging schemas. The less country-specific exceptions the better. Sarah [1] http://nominatim.osm.org/polygons [2] http://nominatim.openstreetmap.org/hierarchy.php?place_id=97944985 (This is for demonstration only, please do not scrape. It will not always give you the expected results anyways because there is a known bug with parenting which still lingers in the DB.) [3] https://github.com/lonvia/Nominatim/blob/export-script/utils/export.php 2013/10/2 Frederik Ramm frede...@remote.org Hi, On 02.10.2013 18:23, César Martínez Izquierdo wrote: I plan to create and make easily available a world-wide administrative layer based on OSM data, ideally including existing administrative codes (ISO, NUTS in Europe, etc) for each level and producing regular updates (for instance once a year). This is something I have been thinking about for a long time (but never written any usable code). Nominatim is probably a good starting point - a better one than MapIt I should think. If you're only after extracting certain relation polygons then you could as well use osmjs (part of Osmium) and have it generate shape files for you, or adapt the shapefile/ogr export samples in Osmium; this will not yet give you a hierarchy, only individual boundaries, and you have to find out the hierarchy yourself. Finding out the hierarchy is going to be tricky. Nominatim does go to some lengths to do that already. It sounds easy (find all polygons with an admin level smaller than X where this polygon I'm looking at lies in). But in reality you will encounter at least: * missing polygons on all levels - sometimes simply not mapped, sometimes missing by design, e.g. Germany has some areas where admin levels 8, 6, and 4 coincide, these are mapped as admin_level 4, so draw a map of all admin_level 8 areas in Germany and you have lots of holes in them * broken polygons on all levels; brokenness changes by the day, i.e. what is working today may be broken tomorrow and vice versa * occasionally (e.g. Japan) linear regional boundaries that simply go from coast to coast without including the coastline * occasionally (e.g. Chile) a regional boundary that is not a multipolygon relation but instead a grouping of smaller regional entities * sometimes small geometric inaccuracies mean that
Re: [OSM-talk] Administrative boundaries export
Thanks Eugene, that looks really promising. I've seen there is an API to query Wikidata (results can be list of Wikidata item IDs encoded as JSON), but I don't see the way to get the item itself as JSON (or any other parseable format). Is it on the way? César 2013/10/3 Eugene Alvin Villar sea...@gmail.com On Thu, Oct 3, 2013 at 6:35 PM, César Martínez Izquierdo cesar@gmail.com wrote: Eugene, I am also interested on your proposal to store on Wikidata a table/database similar to the one described on 1, so any further details on available infrastructure, technologies in use, work already done, etc are welcome. Hi César, you can look at this Wikidata page for the German state of Baden-Württemberg as an example: https://www.wikidata.org/wiki/Q985 It currently contains interesting properties and relationships that may be what we need. Some interesting properties/relations are (especially the OSM one): country=Germany capital=Stuttgart type of administrative division=state of Germany ISO 3166-2=DE-BW GND identifier=4004176-1 contains administrative division=Regierungsbezirk Freiburg, Regierungsbezirk Karlsruhe, Regierungsbezirk Stuttgart, Regierungsbezirk Tübingen is in the administrative unit=Germany OpenStreetMap Relation ID=62611 -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - César Martínez Izquierdo GIS developer - - - - - - - - - - - - - - - - - - - - ETC-SIA: http://sia.eionet.europa.eu/ Universitat Autònoma de Barcelona (SPAIN) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Public, no-cost, general-purpose tile servers
Hi, My university is converting our campus map to use OSM, and I was asked to look in to our options for tiles. Without going down the custom tile route, it seems like most of the publicly available tiles are for special purposes (biking, public transport, etc), and the only general road map style tiles I've found are the Standard tiles and MapQuest Open. Are there any I'm missing? Thanks, --Andrew ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Public, no-cost, general-purpose tile servers
Hi, There are some additional OSM based maps with custom styling, which are provided by University of Heidelberg. You can find them here http://openmapsurfer.uni-hd.de http://openmapsurfer.uni-hd.de/?zoom=13lat=49.48176lon=8.46385layers=B00 Best regards, Max On 10/3/2013 6:36 PM, Andrew Guertin wrote: Hi, My university is converting our campus map to use OSM, and I was asked to look in to our options for tiles. Without going down the custom tile route, it seems like most of the publicly available tiles are for special purposes (biking, public transport, etc), and the only general road map style tiles I've found are the Standard tiles and MapQuest Open. Are there any I'm missing? Thanks, --Andrew ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-legal-talk] About CC-4.0 and ODbl
On 03/10/13 17:21, Rob Myers wrote: On 03/10/13 04:32 AM, Jonathan Harley wrote: On 02/10/13 18:59, Rob Myers wrote: Is it possible to have a BY-SA 4.0 Produced Work? It's possible to give a produced work derived from OSM any license you like (if that's what you mean?) so long as it retains OSM's attribution. Including all rights reserved. But doesn't BY-SA claim to cover the database rights? Doesn't that clash with the ODbL? A produced work isn't a database, so BY-SA 4's (proposed) protection of database rights can't be relevant to it, surely. J. -- Dr Jonathan Harley :Managing Director: SpiffyMap Ltd m...@spiffymap.com Phone: 0845 313 8457 www.spiffymap.com The Venture Centre, Sir William Lyons Road, Coventry CV4 7EZ, UK ___ legal-talk mailing list legal-t...@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] Administrative boundaries export
On Thu, Oct 03, 2013 at 03:31:20PM +0200, César Martínez Izquierdo wrote: That sounds interesting. I am not familiar with Nominatim, but I have correctly understood, the result is a Postgres/postgis database with all those polygons and hierarchies. This could be an interesting approach as the post-processing could be directly done there using PostGIS predicates. Yes, exactly. However, I am not sure about the generated hierarchies, as they don't keep all OSM admin_levels into account (at least in the nomenclature: country, state, county) It keeps the levels internally and also uses the full levels for the hierarchies. The levels are only grouped for output. and I see clear errors for Spain using the link [2] that you provided. It would be interesting to know how these hierarchies are generated (just OSM tags and geometric relations, external database, etc). The hierarchies are built with OSM data only using the tagged admin_levels and relating the polygon geometries. Basically, the parent is defined as the area that covers the object that has the next smaller admin_level. It gets a bit more complicated when place nodes are involved. Sarah 2013/10/3 Sarah Hoffmann lon...@denofr.de On Thu, Oct 03, 2013 at 12:32:36PM +0200, César Martínez Izquierdo wrote: Hi Frederik, regarding software, I am already familiar with Mapit scripts code, which are able to extract admin boundary polygons for each level (it is not creating relationships though). How do you see Nominatim or Osmium/osmjs better for the purpose? Nominatim already does a lot of the stuff you are planning to do. It creates geometries for admin boundaries from OSM data and puts them in a proper hierarchy. It is able to process updates and in the process makes sure that boundaries do not just disappear if somebody breaks the relation. If you only process the data that interests you (boundary=administrative and place nodes) it is not even that resource-hungry. It does have support for listing broken boundaries [1] and during the last hack day Brian has written a proof-of-concept for browsing admin hierarchies[2]. There is even a script to dump objects within a certain boundary[3] which could be easily extended to dump entire hierarchies. All these functions should currently be used with care though. There are known bugs and the output needs to be improved to make them really usable. Basically, most of the work to do would be on the output side, the heavy lifting of processing the data is already done. Well, apart from checking the OSM boundaries against reality. But I think wiki data is a good starting point for that. I will probably try the first option, but I expect that any of them would be costly to maintain if there are frequent changes of the tagging scheme for each country. (But nobody said it would be an easy task :-) Making boundary tagging more visible will hopefully help to stablize and unify the tagging schemas. The less country-specific exceptions the better. Sarah [1] http://nominatim.osm.org/polygons [2] http://nominatim.openstreetmap.org/hierarchy.php?place_id=97944985 (This is for demonstration only, please do not scrape. It will not always give you the expected results anyways because there is a known bug with parenting which still lingers in the DB.) [3] https://github.com/lonvia/Nominatim/blob/export-script/utils/export.php 2013/10/2 Frederik Ramm frede...@remote.org Hi, On 02.10.2013 18:23, César Martínez Izquierdo wrote: I plan to create and make easily available a world-wide administrative layer based on OSM data, ideally including existing administrative codes (ISO, NUTS in Europe, etc) for each level and producing regular updates (for instance once a year). This is something I have been thinking about for a long time (but never written any usable code). Nominatim is probably a good starting point - a better one than MapIt I should think. If you're only after extracting certain relation polygons then you could as well use osmjs (part of Osmium) and have it generate shape files for you, or adapt the shapefile/ogr export samples in Osmium; this will not yet give you a hierarchy, only individual boundaries, and you have to find out the hierarchy yourself. Finding out the hierarchy is going to be tricky. Nominatim does go to some lengths to do that already. It sounds easy (find all polygons with an admin level smaller than X where this polygon I'm looking at lies in). But in reality you will encounter at least: * missing polygons on all levels - sometimes simply not mapped, sometimes missing by design, e.g. Germany has some areas where admin levels 8, 6, and 4 coincide, these are mapped as admin_level 4, so draw a map of all
Re: [OSM-talk] Administrative boundaries export
On Fri, Oct 4, 2013 at 1:35 AM, César Martínez Izquierdo cesar@gmail.com wrote: Thanks Eugene, that looks really promising. I've seen there is an API to query Wikidata (results can be list of Wikidata item IDs encoded as JSON), but I don't see the way to get the item itself as JSON (or any other parseable format). Is it on the way? Unfortunately, I am not up-to-par with the API side of Wikidata. I assume that every bit of data on Wikidata can or will be accessible through APIs. Otherwise, it would limit the usefulness of Wikidata if we resort to scraping the HTML page. 2013/10/3 Eugene Alvin Villar sea...@gmail.com On Thu, Oct 3, 2013 at 6:35 PM, César Martínez Izquierdo cesar@gmail.com wrote: Eugene, I am also interested on your proposal to store on Wikidata a table/database similar to the one described on 1, so any further details on available infrastructure, technologies in use, work already done, etc are welcome. Hi César, you can look at this Wikidata page for the German state of Baden-Württemberg as an example: https://www.wikidata.org/wiki/Q985 It currently contains interesting properties and relationships that may be what we need. Some interesting properties/relations are (especially the OSM one): country=Germany capital=Stuttgart type of administrative division=state of Germany ISO 3166-2=DE-BW GND identifier=4004176-1 contains administrative division=Regierungsbezirk Freiburg, Regierungsbezirk Karlsruhe, Regierungsbezirk Stuttgart, Regierungsbezirk Tübingen is in the administrative unit=Germany OpenStreetMap Relation ID=62611 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-br] RES: Dados IBGE e CEPs
Bom dia Vitor, O mapa é apenas uma tela de fundo, no momento sem muita função, o pin fica posicionado na localidade que esteja sendo pesquisada. Selecione uf, conforme for digitando a nome da cidade, e depois o nome do logradouro, a partir da 3 ou 4 letra o programa apresenta uma lista do que combina com o que você esta digitando. Ah o nome das ruas deve ser digitado sem o tipo ( rua, avenida, etc...), mas deve ter os títulos ( duque, barão, etc...). Estou padronizando tudo em caixa alta e sem acentuação. Quando tiver selecionado a rua, será apresentado o cep, no campo número você o autocomplete começa no primeiro digito, serve também para verificar se um endereço é real. Faça por exemplo uma pesquisa com meu endereço comercial – SP – SÃO PAULO – BENTO FREITAS – 162 Pesquisas na cidade de São Paulo é claro são o pior caso pela quantidade de registros no banco de dados. E como eu disse ainda estou padronizando os nomes das Ruas então pode ter coisa que você não encontre. Depois de ter padronizado o nome dos logradouros vou processar os arquivos para verificar e validar os CEPs pois eu possuo a base de CEPs do correio licenciada para esse tipo de processamento. Abraços Reinaldo De: Vitor George [mailto:vitor.geo...@gmail.com] Enviada em: quarta-feira, 2 de outubro de 2013 19:57 Para: OSM talk-br Assunto: Re: [Talk-br] Dados IBGE e CEPs Oi Reinaldo, Tentei fazer uma busca, mas só aparece um pin no mapa no meio de São Paulo. Você pode dar um exemplo de busca que posso fazer? Abs, Vitor 2013/10/2 Reinaldo Neves rne...@equacao.com.br Prezados, A um tempo atrás vi na lista uma consulta sobre agregar o CEP nos dados OSM, sei que a base cos correios não pode ser em principio ser utilizada por uma possível proteção desses dados, coisa com a qual não concordo pois o CEP em si é publico, proteção e direito autoral até onde vejo é possível para definição de tabelas, relacionamentos, etc... De qualquer maneira consegui a base do CNEFE (Cadastro Nacional de Endereços para Fins Censitários) onde não há essa restrição, até porque o próprio IBGE define que as informações são fornecidas pelos entrevistados. Ainda estou fazendo um trabalho de padronização nos endereços, pois há nomes de ruas com grafias diferentes dependendo de fonética, instrução do entrevistado e do entrevistador e até mesmo alguns endereços por referência, especialmente em áreas rurais. De qualquer maneira disponibilizei uma primeira forma de pesquisa no endereço www.pepbr.com.br, caso considerem utilizável por favor fiquem a vontade. Atenciosamente ___ cid:AEB89D39-0ED3-48AF-9EB7-EF84C2B4BC40 Reinaldo Neves Equação Informática (: (11) 3221-3722 tel:%2811%29%203221-3722 *: rne...@equacao.com.br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br attachment: image001.jpg ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] RES: Dados IBGE e CEPs
Muito legal, consegui fazer funcionar. Eu tenho um projeto (abandonado) de usar esta base como referência para verificar a qualidade dos endereços mapeados no OSM. Avise se resolver abrir do código-fonte, talvez possamos compartilhar algo. Abs, Vitor 2013/10/3 Reinaldo Neves rne...@equacao.com.br Bom dia Vitor, ** ** O mapa é apenas uma tela de fundo, no momento sem muita função, o pin fica posicionado na localidade que esteja sendo pesquisada. ** ** Selecione uf, conforme for digitando a nome da cidade, e depois o nome do logradouro, a partir da 3 ou 4 letra o programa apresenta uma lista do que combina com o que você esta digitando. Ah o nome das ruas deve ser digitado sem o tipo ( rua, avenida, etc...), mas deve ter os títulos ( duque, barão, etc...). ** ** Estou padronizando tudo em caixa alta e sem acentuação. Quando tiver selecionado a rua, será apresentado o cep, no campo número você o autocomplete começa no primeiro digito, serve também para verificar se um endereço é real. ** ** Faça por exemplo uma pesquisa com meu endereço comercial – SP – SÃO PAULO – BENTO FREITAS – 162 ** ** Pesquisas na cidade de São Paulo é claro são o pior caso pela quantidade de registros no banco de dados. E como eu disse ainda estou padronizando os nomes das Ruas então pode ter coisa que você não encontre. ** ** Depois de ter padronizado o nome dos logradouros vou processar os arquivos para verificar e validar os CEPs pois eu possuo a base de CEPs do correio licenciada para esse tipo de processamento. ** ** Abraços ** ** Reinaldo ** ** *De:* Vitor George [mailto:vitor.geo...@gmail.com] *Enviada em:* quarta-feira, 2 de outubro de 2013 19:57 *Para:* OSM talk-br *Assunto:* Re: [Talk-br] Dados IBGE e CEPs ** ** Oi Reinaldo, ** ** Tentei fazer uma busca, mas só aparece um pin no mapa no meio de São Paulo. ** ** Você pode dar um exemplo de busca que posso fazer? ** ** Abs, Vitor ** ** ** ** 2013/10/2 Reinaldo Neves rne...@equacao.com.br Prezados, A um tempo atrás vi na lista uma consulta sobre agregar o CEP nos dados OSM, sei que a base cos correios não pode ser em principio ser utilizada por uma possível proteção desses dados, coisa com a qual não concordo pois o CEP em si é publico, proteção e direito autoral até onde vejo é possível para definição de tabelas, relacionamentos, etc... De qualquer maneira consegui a base do CNEFE (Cadastro Nacional de Endereços para Fins Censitários) onde não há essa restrição, até porque o próprio IBGE define que as informações são fornecidas pelos entrevistados. Ainda estou fazendo um trabalho de padronização nos endereços, pois há nomes de ruas com grafias diferentes dependendo de fonética, instrução do entrevistado e do entrevistador e até mesmo alguns endereços por referência, especialmente em áreas rurais. De qualquer maneira disponibilizei uma primeira forma de pesquisa no endereço www.pepbr.com.br, caso considerem utilizável por favor fiquem a vontade. Atenciosamente ___ [image: cid:AEB89D39-0ED3-48AF-9EB7-EF84C2B4BC40] Reinaldo Neves Equação Informática (: (11) 3221-3722 ***: rne...@equacao.com.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 attachment: image001.jpg ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] Oruxmaps suspenso do Google Play
Olá há algum tempo a gente comentou sobre o aplicativo Android Oruxmapshttp://www.oruxmaps.com/index_en.html. É um dos meus programas favoritos e eu uso muito para fazer tracklogs de GPS. Há alguns dias o Oruxmaps sumiu do Google Play. Agora voltou sem os mapas online do Google e da Microsoft. Nâo achei nenhum comentário específico, mas parece que teve problemas de Copyright e por isto foi suspenso. Para mim, taí mais uma razão para investir no OSM abraços Gerald ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Oruxmaps suspenso do Google Play
Eu praticamente só uso o OSM no OruxMaps, é realmente muito bom. Quando viajo eu marco todos os pontos no Google Maps (o OSM ainda não é tão completo), daí exporto o KML e importo no OruxMaps. Daí navego um pouco na área que eu vou visitar pra ele fazer cache dos tiles, e daí posso passear a vontade sem mapas em papel. On Oct 3, 2013 6:47 PM, Gerald Weber gwebe...@gmail.com wrote: Olá há algum tempo a gente comentou sobre o aplicativo Android Oruxmapshttp://www.oruxmaps.com/index_en.html. É um dos meus programas favoritos e eu uso muito para fazer tracklogs de GPS. Há alguns dias o Oruxmaps sumiu do Google Play. Agora voltou sem os mapas online do Google e da Microsoft. Nâo achei nenhum comentário específico, mas parece que teve problemas de Copyright e por isto foi suspenso. Para mim, taí mais uma razão para investir no OSM abraços Gerald ___ 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] Oruxmaps suspenso do Google Play
Não conhecia. Tem apk disponível no site? É opensource? Uso mais o Vespucci e o OsmAnd mesmo. On Oct 3, 2013 9:23 PM, Fernando Trebien fernando.treb...@gmail.com wrote: Eu praticamente só uso o OSM no OruxMaps, é realmente muito bom. Quando viajo eu marco todos os pontos no Google Maps (o OSM ainda não é tão completo), daí exporto o KML e importo no OruxMaps. Daí navego um pouco na área que eu vou visitar pra ele fazer cache dos tiles, e daí posso passear a vontade sem mapas em papel. On Oct 3, 2013 6:47 PM, Gerald Weber gwebe...@gmail.com wrote: Olá há algum tempo a gente comentou sobre o aplicativo Android Oruxmapshttp://www.oruxmaps.com/index_en.html. É um dos meus programas favoritos e eu uso muito para fazer tracklogs de GPS. Há alguns dias o Oruxmaps sumiu do Google Play. Agora voltou sem os mapas online do Google e da Microsoft. Nâo achei nenhum comentário específico, mas parece que teve problemas de Copyright e por isto foi suspenso. Para mim, taí mais uma razão para investir no OSM abraços Gerald ___ 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] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo Peter, dein Misstrauen finde ich etwas unverständlich. All die Fehlertools zeigen nicht Fehler an, sondern mögliche Fehler. Ob das letztlich ein Fehler ist muss der Mapper dann erst überprüfen. Bei manchen Fehlern geht das aus der Ferne, bei anderen braucht man Ortskenntnis. Aus diesem Grund würde ich mir beim OSMI eher die Möglichkeit wünschen, einen Fehler als erledigt bzw. als falschen Fehler zu markieren. Bei den falschen Fehlern wäre es natürlich hilfreich, wenn diese auch nach dem Aktualisieren der Datengrundlage erhalten bleibt. Fehleransichten ala Info am Punkt passt nicht zur Info am umgebenen Polygon wäre auf jedenfall sinnvoll. Henning -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32) iQEcBAEBAgAGBQJSTRuTAAoJEPFgsWC7jOeT8EAIALn8pEkQLmPLHTojB5yFCa28 6R3efsrbPtJbhAjQ032MM72nPn2ooV5Cz8jhaCJcwOQVcVpKr54xtykz/rvmPknA /vOiQilyIsQBJhRXQT04s7oG6F31GoQGGRTF+x9xb5GPOI2ShYEp0H/EQtBFS80B 0SEtxyxGuY2LcKLZMc5+gxMMLeRV50lffdBgj0xSLEwqDkIMaQIP6NvKWFnR79pJ 8YCgWR5EYhGD6GN33vRCQV1Rxm8q5ZgV+DBRqG+N5+5oIaiPBLDucWRdMozRnI6e Mw5xxt2Y0/ggk+GjY851bbzz2QQFx5kMvB8OyV/46Bvmx2+CWx8GA8ylpPeN3cY= =NpHo -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Schienen mit abandoned
Hallo fly, danke für die freundliche Antwort. Lese nun seit ca. 1 Monat mit und weiss, dass das der übliche Umgangston hier ist. Aber wie wäre es mit nachschauen? Es handelt sich hier um eine ehemalige Bahnstrecke, die seit ca. 30 Jahren stillgelegt ist und eben bis auf zerfallene Brücken und den Schotteruntergrund fast nichts mehr da ist und wo jetzt eine meist ortsnahe Radstrecke eröffnet wurde. Gruß Bernhard Da hast Du mich falsch verstanden. Ich suche ganz bestimmte Gleise an einem bestimmten Ort, welche schon lange nicht mehr benutzt werden aber eben mittlerweile bis auf Schotter nichts mehr da ist. fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gelöschte Linien finden und wieder herstellen
ein Server, der die gesamte Historie von OSM enthält und den Download der Daten eines (kleinen) Gebiets zu einem wählbaren Datum erlaubt, wäre für solche Probleme sehr nützlich. Damit könnte man auch die zeitliche Entwicklung eines Gebiets oder die Veränderungen durch ein Changeset visualisieren. Gibt es Überlegungen, so etwas einzurichten? Ich arbeite gerade daran, die Overpass API auch auf die Vergangenheit auszudehnen. Wird avoraussichtlich bis Weihnachten dauern. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schienen mit abandoned
Hallo Bernhard, stillgelegte und seit längerem nicht mehr bestehende Bahnlinien einzutragen hat bei OSM Tradition. Dafür sprechen aus meiner Sicht die folgenden Aspekte: 1. gibt es sehr enthusiastischen Bahnfreunde, die sich freuen, wenn es eine Darstellungsmöglichkeit für alte Bahnstrecken gibt. Damit sind abgebaute Bahnschienen die wenigen historischen Elemente, die bei OSM akzeptiert sind und gepflegt werden. 2. Ist nach deiner Aussage sogar noch etwas von der Bahnlinie in der Wirklichkeit erkennbar, so dass es in diesem Fall auch kein Verstoß gegen die on the ground rule wäre. 3. Verträgt sich das Tag sehr gut mit anderen Tags, wie beispielsweise Radwegen. Hängen beide Tags gemeinsam an einem Wegelement hat das sogar eine nützliche Zusatzfunktion -- der Radfahrer und der Router wissen dann, das die Strecke sehr gemächlich verläuft bzw. ansteigt. Ich sehe daher im Augenblick daher keine Notwendigkeit das in Zunkunft anders zu behandeln. Viele Grüße Falk Am 3. Oktober 2013 10:06 schrieb Bernhard Kuisle bernhard.kui...@web.de: Hallo fly, danke für die freundliche Antwort. Lese nun seit ca. 1 Monat mit und weiss, dass das der übliche Umgangston hier ist. Aber wie wäre es mit nachschauen? Es handelt sich hier um eine ehemalige Bahnstrecke, die seit ca. 30 Jahren stillgelegt ist und eben bis auf zerfallene Brücken und den Schotteruntergrund fast nichts mehr da ist und wo jetzt eine meist ortsnahe Radstrecke eröffnet wurde. Gruß Bernhard Da hast Du mich falsch verstanden. Ich suche ganz bestimmte Gleise an einem bestimmten Ort, welche schon lange nicht mehr benutzt werden aber eben mittlerweile bis auf Schotter nichts mehr da ist. fly ___ 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] Schienen mit abandoned
Am 3. Oktober 2013 10:06 schrieb Bernhard Kuisle bernhard.kui...@web.de: danke für die freundliche Antwort. Lese nun seit ca. 1 Monat mit und weiss, dass das der übliche Umgangston hier ist. Aber wie wäre es mit nachschauen? Es handelt sich hier um eine ehemalige Bahnstrecke, die seit ca. 30 Jahren stillgelegt ist und eben bis auf zerfallene Brücken und den Schotteruntergrund fast nichts mehr da ist und wo jetzt eine meist ortsnahe Radstrecke eröffnet wurde. Ihr redet aneinander vorbei, er sucht die eine bestimmte Strecke, die er eingetragen hat, und die in der Zwischenzeit jemand gelöscht hat, Du beziehst Dich auf eine andere (ggf. ähnliche) Strecke, aber vermutlich will fly die eigene Strecke wiederherstellen (undelete) und sucht daher deren osm-id. Von daher kann er mit einer anderen, ähnlichen Strecke nichts anfangen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Offline Cache bei JOSM
On Wed, Oct 02, 2013 at 05:29:52PM +0200, Thorsten Alge wrote: Hi, ich nutze meine vielen Zugfahrten gerne um gesammelte Infos per JOSM einzutragen oder Gebäude von Bing abzuzeichnen. Leider habe ich mit dem Tile-Cache bei JOSM so ein paar Probleme. 1) Bereiche die geladen wurden, verschwinden nach dem raus- und wieder rein zoomen und müssen neu runtergeladen werden. 2) Der Cache scheint häufig geleert zu werden. Kann ich JOSM so einstellen, dass er Tiles über einen längeren Zeitraum vorhält und nur bei Änderungen neu lädt? Vielleicht hat sich der Eine oder Andere von euch schon mal mit dem Problem konfrontiert gesehen und kann mir ein paar Tips geben? Bei mir war der cache standardmaessig in /tmp (Linux) und das tmp wird beim reboot halt geloescht. Ich habe das dann verschoben - problem war dann das ich am ende ~50 files in einem verzeichniss hatte. 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] Normale Straße ?=mit =?utf-8?Q?area=yes
Was haltet ihr davon? Kommt mir z.b. bei http://www.openstreetmap.org/browse/way/206802933 ziemlich überflüssig vor. Beim Tempelhofes Feld macht das ja noch Sinn, aber hier kann ich mir keinerlei Vorteile, auch nicht fürs Routing denken. Gruß, Leo ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp
Hi Peter, Am Mittwoch, den 02.10.2013, 23:53 +0200 schrieb Peter: Am 01.10.2013 20:56, schrieb Peter Wendorff: Am 01.10.2013 17:10, schrieb tumsi: Dazu fänd ich ein missing post-code noch gut (oder seh ich das nicht?). [...] Deshalb schadet Redundanz hier nicht. Ich widerspreche vehement. +1 Man darf die Eigenheiten der Menschen nicht vernachlässigen. Gerade die der deutschen (genau, korrekt, Fehler werden ausgemerzt :-): [...] Am Ende haben wir nicht redundante Daten sondern das Gegenteil: Die addr:postcode passen 100% zu den PLZ-Polygonen und alles sieht toll aus. Nur das die addr: 'falsch' sind da nicht vor Ort geprüft, oder aus unabhängiger Quelle. Am ende scheinen sich die Daten gegenseitig zu 'beweisen', obwohl sie falsch sind. +100 Als Auswerter / Nutzer reicht durchaus ein Wert. Bei zwei Werten ist es durchaus ein Problem automatisch zu entscheiden welcher Wert richtig ist. Daher ist die GK-PLZ in addr:postcode außerhalb der PLZ-Relation ungünstig. Mein Vorschlag dazu wäre addr:letter_postcode. PLZ gehören IMHO daher nur in die entsprechende Relation und nicht an die Nodes / Ways. Laut [3] gibt es in Deutschland ca. 19.000.000 Wohngebäude. Wenn alle Gebäude ein addr:postcode - Tag hätten wäre das allein für Deutschland (14+6) * 19.000.000 ~ 380MByte an Daten die eingespart werden könnten. [...] Hierzu: wie kann man denn eine verlässliche Datenquelle für die PLZ Gebiete bekommen? Eigentlich gar nicht, da sich zumindest alle 3 Monate einiges geändert wird. [1] Oder warten wir einfach bis die Post angekrochen kommt und uns die Daten anbietet. Irgendwann werden sie es tun, denn es kann nur eine [2] geben. Hat dort schon mal jemand nachgefragt? Und wenn ja mit welchem Ergebnis? Und so schlimm kann es mit der Fehlerrate bei den PLZ-Relationen nicht sein. Hier steht ziemlich viel auf 100% [2]. Wobei sich mir gerade die Frage aufdrängt warum Sendungen mit falscher PLZ trotzdem zugestellt werden. Schönen Sonntag noch Jörg [1] http://www.deutschepost.de/dpag?tab=1skin=hicheck=yeslang=de_DExmlFile=1010980 [2] http://wiki.openstreetmap.org/wiki/Import/Catalogue/Postleitzahlen_Deutschland_2010/Todo [3] https://www.destatis.de/DE/PresseService/Presse/Pressekonferenzen/2013/Zensus2011/gwz_zensus2011.pdf?__blob=publicationFile -- Jörg Frings-Fürst OSM privat D-54526 Landscheid GPG Fingerprint: 13E3 4D4A 3228 D138 8511 EA5A 08AC AF02 3C6D 750A Full GPG key: hkp://pool.sks-keyservers.net CAcert Serialnr.: 0D:9A:23 SHA1-Fingerprint: CA:36:4D:44:D1:71:4A:78:C8:6C:C2:CC:94:F3:6E:42:38:BA:CE:4E http://cacert.org signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Normale Straße ?=mit =?utf-8?Q?area=yes
Am 3. Oktober 2013 13:32 schrieb Leo Koppelkamm he...@leo-koppelkamm.de: Was haltet ihr davon? Kommt mir z.b. bei http://www.openstreetmap.org/browse/way/206802933 ziemlich überflüssig vor. Beim Tempelhofes Feld macht das ja noch Sinn, aber hier kann ich mir keinerlei Vorteile, auch nicht fürs Routing denken. m.E. ist das highway=residential ein tagging für den Renderer und sollte entfernt werden. Das area:highway=residential, welches der way ja auch schon hat, sowie die anderen tags wie surface etc. sind OK. Gerade fürs Routing ist der way, so wie er jetzt getaggt ist, zumindest potenziell schädlich, auch wenn er derzeit nicht mit dem highway-Netz verbunden sein sollte. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Normale Straße ?=mit =?utf-8?Q?area=yes
Hallo Leo, Am Donnerstag, den 03.10.2013, 13:32 +0200 schrieb Leo Koppelkamm: Was haltet ihr davon? Kommt mir z.b. bei http://www.openstreetmap.org/browse/way/206802933 ziemlich überflüssig vor. Beim Tempelhofes Feld macht das ja noch Sinn, aber hier kann ich mir keinerlei Vorteile, auch nicht fürs Routing denken. [...] ich sehe dort keinen Fehler. Die Straße ist als Way und als Area eingetragen. Hintergedanke dürfte sein das es keine weißen Flecken zwischen der Straße und den angrenzenden Flächen gibt. Das funktioniert aber nur wenn die Renderer das auch auswertet. Bis heute habe ich keine passende Karten gesehen. Gruß Jörg -- Jörg Frings-Fürst OSM privat D-54526 Landscheid GPG Fingerprint: 13E3 4D4A 3228 D138 8511 EA5A 08AC AF02 3C6D 750A Full GPG key: hkp://pool.sks-keyservers.net CAcert Serialnr.: 0D:9A:23 SHA1-Fingerprint: CA:36:4D:44:D1:71:4A:78:C8:6C:C2:CC:94:F3:6E:42:38:BA:CE:4E http://cacert.org signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Normale Straße ?=mit =?utf-8?Q?area=yes
Am 03.10.2013 14:22, schrieb Jörg Frings-Fürst: Am Donnerstag, den 03.10.2013, 13:32 +0200 schrieb Leo Koppelkamm: Was haltet ihr davon? Kommt mir z.b. bei http://www.openstreetmap.org/browse/way/206802933 ziemlich überflüssig vor. Beim Tempelhofes Feld macht das ja noch Sinn, aber hier kann ich mir keinerlei Vorteile, auch nicht fürs Routing denken. [...] ich sehe dort keinen Fehler. Die Straße ist als Way und als Area eingetragen. Dagegen ist erst einmal nichts zu sagen und das Tagging mit area:highway=residential + surface=asphalt wäre für sich genommen auch korrekt. Leider wurden zusätzlich noch highway=residential + area=yes gesetzt, die aber nicht die Fläche einer Straße, sondern einen Platz kennzeichnen. Und das ist dann eben doch ein Fehler, diese beiden Tags sollten entfernt werden. Gruß, Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp
Am 3. Oktober 2013 14:03 schrieb Jörg Frings-Fürst o...@jff-webhosting.net: Am Mittwoch, den 02.10.2013, 23:53 +0200 schrieb Peter: Am 01.10.2013 20:56, schrieb Peter Wendorff: Am 01.10.2013 17:10, schrieb tumsi: Deshalb schadet Redundanz hier nicht. Ich widerspreche vehement. +1 -1 Als Auswerter / Nutzer reicht durchaus ein Wert. Bei zwei Werten ist es durchaus ein Problem automatisch zu entscheiden welcher Wert richtig ist. Daher ist die GK-PLZ in addr:postcode außerhalb der PLZ-Relation ungünstig. Mein Vorschlag dazu wäre addr:letter_postcode. PLZ gehören IMHO daher nur in die entsprechende Relation und nicht an die Nodes / Ways. gerade weil man es nicht automatisch entscheiden kann, und weil relationen prinzipiell komplexer sind als tags on nodes, würde ich tendenziell eher einer PLZ an einem Node trauen als einer Relation. Alle PLZ die ich an Nodes gehangen habe, kommen von Dingen wie Kassenzetteln oder in anderer Weise von dem jeweiligen Nutzer (Internetseiten etc.). Klar kann man da auch Fehler nicht ausschließen, von daher sollte nichts automatisch gemacht werden, sondern diese Diskrepanzen durch Recherche aufgeklärt werden. Wenn man aber rein auf Relationen setzt entgehen einem sicherlich viele solcher Fehler und schlummern potentiell sehr lange in der db. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schienen mit abandoned
On 03.10.2013 12:49, Martin Koppenhoefer wrote: Am 3. Oktober 2013 10:06 schrieb Bernhard Kuisle bernhard.kui...@web.de: Hey Liste, lieber Bernhard Da hast Du mich falsch verstanden. Ich suche ganz bestimmte Gleise an einem bestimmten Ort, welche schon lange nicht mehr benutzt werden aber eben mittlerweile bis auf Schotter nichts mehr da ist. fly danke für die freundliche Antwort. Lese nun seit ca. 1 Monat mit und weiss, dass das der übliche Umgangston hier ist. Ich weiß leider nicht was an meiner Antwort unfreundlich gewesen sein soll. Im Gegenteil, ich habe ja geantwortet anstatt einfach drüber weg zu gehen. Wenn Du eher ein Antwort zu Deiner Strecke hättest haben wollen, wäre ein eigener Thread die richtige Lösung gewesen. Aber wie wäre es mit nachschauen? Es handelt sich hier um eine ehemalige Bahnstrecke, die seit ca. 30 Jahren stillgelegt ist und eben bis auf zerfallene Brücken und den Schotteruntergrund fast nichts mehr da ist und wo jetzt eine meist ortsnahe Radstrecke eröffnet wurde. Ihr redet aneinander vorbei, er sucht die eine bestimmte Strecke, die er eingetragen hat, und die in der Zwischenzeit jemand gelöscht hat, Du beziehst Dich auf eine andere (ggf. ähnliche) Strecke, aber vermutlich will fly die eigene Strecke wiederherstellen (undelete) und sucht daher deren osm-id. Von daher kann er mit einer anderen, ähnlichen Strecke nichts anfangen. +1 Allerdings wurde ich in der Zwischenzeit darauf aufmerksam gemacht, dass raized wohl doch nicht passt, da ja noch das Schotterbett erhalten ist. Witziger weise, habe ich den Tipp nur erhalten, weil der neue HOT-Stil mit railway=razed nicht umgehen kann und die Linien als normale Stecke dargestellt werden. Cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp
Hallo Martin, Am Donnerstag, den 03.10.2013, 14:51 +0200 schrieb Martin Koppenhoefer: Am 3. Oktober 2013 14:03 schrieb Jörg Frings-Fürst o...@jff-webhosting.net: [...] Als Auswerter / Nutzer reicht durchaus ein Wert. Bei zwei Werten ist es durchaus ein Problem automatisch zu entscheiden welcher Wert richtig ist. Daher ist die GK-PLZ in addr:postcode außerhalb der PLZ-Relation ungünstig. Mein Vorschlag dazu wäre addr:letter_postcode. PLZ gehören IMHO daher nur in die entsprechende Relation und nicht an die Nodes / Ways. gerade weil man es nicht automatisch entscheiden kann, und weil relationen prinzipiell komplexer sind als tags on nodes, würde ich tendenziell eher einer PLZ an einem Node trauen als einer Relation. Alle PLZ die ich an Nodes gehangen habe, kommen von Dingen wie Kassenzetteln oder in anderer Weise von dem jeweiligen Nutzer (Internetseiten etc.). Klar kann man da auch Fehler nicht ausschließen, von daher sollte nichts automatisch gemacht werden, sondern diese Diskrepanzen durch Recherche aufgeklärt werden. Wenn man aber rein auf Relationen setzt entgehen einem sicherlich viele solcher Fehler und schlummern potentiell sehr lange in der db. Also irgendwie verstehe ich die Logik dahinter nicht. Aber mal von Anfang an: PLZ ist ein Merkmal eines geografischen Zustellgebietes. Und sie ist in diesem Gebiet für alle Grundstücke gültig. Damit gibt es eine eindeutige Zuordnung PLZ -- Grundstück. Jetzt sagst Du das Du den PLZ an Nodes / Gebäuden / Ways mehr traust. Gut. Nur was heißt das? Die vorhandenen Daten sind nicht brauchbar, da nur mit Ortskenntnis oder mit 3. Mitteln die Korrektheit überprüft werden kann. Hier drängt sich die Frage auf: Warum werden potentiell falsche Daten erfasst? Ich denke mal hier sollte wie bei is_in die Relationen korrigieren und dann die addr:postcode Tags an den Nodes auslaufen lassen. Dafür spricht auch die leichtere Überprüfbarkeit, schnellere Korrektur und das verringerte Datenvolumen. Gruß Jörg -- Jörg Frings-Fürst OSM privat D-54526 Landscheid GPG Fingerprint: 13E3 4D4A 3228 D138 8511 EA5A 08AC AF02 3C6D 750A Full GPG key: hkp://pool.sks-keyservers.net CAcert Serialnr.: 0D:9A:23 SHA1-Fingerprint: CA:36:4D:44:D1:71:4A:78:C8:6C:C2:CC:94:F3:6E:42:38:BA:CE:4E http://cacert.org signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Normale Straße ?=mit =?utf-8?Q?area=yes
On Thu, Oct 03, 2013 at 01:32:28PM +0200, Leo Koppelkamm wrote: Was haltet ihr davon? Kommt mir z.b. bei http://www.openstreetmap.org/browse/way/206802933 ziemlich überflüssig vor. Beim Tempelhofes Feld macht das ja noch Sinn, aber hier kann ich mir keinerlei Vorteile, auch nicht fürs Routing denken. Da hat jemand angefangen Straßen als Flächen zu mappen. Ich hoffe das ist zusaetzlich zu der Straße in der Mitte. Werden wir alle irgendwann mal machen - In den Städten kommt halt die Langeweile früher weil alle Kieselsteine gemappt sind. Wenn der Way für die Straße darunter liegt halte ich das nicht für falsch - nur ungewohnt. 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
Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp
Hola, On Wed, Oct 02, 2013 at 11:53:18PM +0200, Peter wrote: Wenn da in OSMI ein Layer auftaucht mit fehlenden PLZ an Adressen, so finden sich sicher ein paar Mapper die durch die Lande ziehen, also nie vor Ort waren, und die Korrigieren/Nachtragen. Und zwar gut gemeint aus den PLZ-Polygonen. [1] Da verwette ich meinen * drauf. Da werden Leute hingehen und mit Josm und filtern ganzen Stadtteilen PLZ verpassen, nach den ungenauen/falschen Polygonen. Na - ein Hirn brauch man definitiv wenn man Josm startet. Walters plz Karte ist so wie sie ist doch gut für die PLZ. Vielleicht sollten wir damit erstmal die PLZ Gebiete hier vervollständigen/korrigieren und dann später mit einem OSMI Layer die echten Fehler aufzeigen. Hierzu: wie kann man denn eine verlässliche Datenquelle für die PLZ Gebiete bekommen? Es gibt keine - Ich glaube nicht das die Deutsche Post stand heute Polygone hat. Ich glaube auch nicht das irgendjemand wirklich mit den Polygonen arbeitet um absolut korrekte informationen zu erarbeiten. Das was die Post da in der Abfrage rauswirft a la Straße A 1-399 PLZ XYZ Straße A 400-1200 PLZ ABC sind die korrekten Daten. Andere haben da vielleicht mal mit hilfe eine geocoders polygone draus gemacht. Die sind aber so ungenau wie die WLAN Ortung im Android. Und die Gutmapper werden durch die Lande ziehen und jedem $Dings country/postcode verpassen. Ich halte addr:postcode/county an jedem $Dings eher für was wie Spam. Sehe ich nicht so - addr: objekte sollten immer VOLLSTÄNDIGE Adressinformationen beinhalten und nicht irgendwelchen verkrüppelte Daten wo die andere hälfte basierend auf irgendwelchen geographischen ratespielchen dazuergänzt werden muss. Wenn man das weiter treibt sind demnächst nur noch Housenumbers dran solange man die Straße zuordnen kann a la - die naechste Straße. Und der nächste Schritt ist das man nur noch auf dem ersten Gebäude die 1 macht - den anderen krams kann man ja durchzählen oder? Die Argumentation das man alles weglässt was man anders ermitteln kann ist demnach beliebig ad absurdum zu führen. 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
Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp
On Thu, Oct 03, 2013 at 02:03:18PM +0200, Jörg Frings-Fürst wrote: die Nodes / Ways. Laut [3] gibt es in Deutschland ca. 19.000.000 Wohngebäude. Wenn alle Gebäude ein addr:postcode - Tag hätten wäre das allein für Deutschland (14+6) * 19.000.000 ~ 380MByte an Daten die eingespart werden könnten. Kompression? Und 380MByte geht vielleicht nicht mehr auf meine Amiga DD Floppy von 1986, stellt aber mittlerweile eine lächerlich kleine Datenmenge dar. CDs als FLAC rippen und hier auf 380MByte hinweisen *ROFL* 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
Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp
On Thu, Oct 03, 2013 at 04:46:53PM +0200, Jörg Frings-Fürst wrote: Aber mal von Anfang an: PLZ ist ein Merkmal eines geografischen Zustellgebietes. Und sie ist in diesem Gebiet für alle Grundstücke gültig. Damit gibt es eine eindeutige Zuordnung PLZ -- Grundstück. Das alleine bestreite ich schon. Eine Postleitzahl ist ein Technisches Hilfsmittel der Deutschen Post um Gruppen von Adressen zu bilden. Diese hat den Zweck der einfachen überregionalen Logistik. Diese Gruppen wurden zum einen basierend auf der Geographischen lage aber eben auch nach anderen Kriterien erzeugt. So hat man gerne vollständige Straßenzüge genommen auch wenn diese eigentlich in andere PLZ Bereiche reichen. Teilweise sind Postleitzahlen auch nur Inseln die von anderen Postleitzahlen vollständig umschlossen werden. Die Polygone die wir derzeit haben berücksichtigen die vollständigkeit der Straßenzüge nicht, sondern sind lediglich grobe richtwerte welche Masse von Adressen zu einer PLZ gehören. D.h. teilweise muss das PLZ Polygon angepasst werden, teilweise die Adressen. Aber das ist wie mit maxspeeds. Um die wirklich sauber hinzubekommen mappe ich mittlerweile die Schilder der Geschwindigkeitsbeschränkungen, anders sind Asymmetrische maxspeeds nicht in den Griff zu bekommen. Selbiges gilt für die PLZ Polygone. Diese wird man nur sehr mühsam korrigiert bekommen wenn man nicht nach und nach die Adressen richtig einträgt und dann nach und nach das anpasst. 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
Re: [Talk-de] ID
Hallo, Am Donnerstag, den 03.10.2013, 01:03 +0200 schrieb Martin Raifer: Am 03.10.2013, 00:49 Uhr, schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de: Dann hat diese Übersetzung bei mir keine Auswirkungen. Eine Einstellung der Sprache habe ich nicht gefunden. Ich sehe nur den englischen Text. Hm. Komisch. iD übernimmt eigentlich die Sprache, die im OSM-Account (unter Bevorzugte Sprachen bzw. Preferred Languages) eingestellt ist. Ist das bei dir Deutsch (bzw. de oder de-DE)? Die Einstellung bei mir ist de-DE,en-US,en Wird die restliche OSM-Website auf deutsch angezeigt? Ist nur die Einführung/Walkthrough nicht übersetzt, oder die gesamtem Benutzerelemente von iD? Die OSM-Webseite läuft komplett auf Deutsch. Der ID läuft komplett auf Englisch. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Redundanz in den addr: tags - vs postcode polygon Was: Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp
On Thu, Oct 03, 2013 at 02:03:18PM +0200, Jörg Frings-Fürst wrote: Laut [3] gibt es in Deutschland ca. 19.000.000 Wohngebäude. Wenn alle Gebäude ein addr:postcode - Tag hätten wäre das allein für Deutschland (14+6) * 19.000.000 ~ 380MByte an Daten die eingespart werden könnten. Um das ganze nochmal zu untermauern - Es ist nicht ganz Deutschland, es fehlt ein kleiner Teil Süddeutschlands in meinen Datenbeständen aber hier mal: db= \o plz db= select 'addr:postcode=' || plz from addr; flo@p2:~$ head plz ?column? - addr:postcode=12557 addr:postcode=12557 addr:postcode=06268 addr:postcode=12557 addr:postcode=06268 addr:postcode=06268 addr:postcode=12557 addr:postcode=18311 flo@p2:~$ wc -l plz 19363585 plz flo@p2:~$ gzip -9c plz plz.gz flo@p2:~$ ls -la plz* -rw-r--r-- 1 flo flo 406635262 Oct 3 15:22 plz -rw-r--r-- 1 flo flo 17933799 Oct 3 15:24 plz.gz Also über 18MByte reden wir ... Ein Bild mit der 20MPixel Kamera oder ein Song in der MP3 collection oder 1/4 meiner inbox: flo@p2:~$ ls -la Mail/inbox -rw--- 1 flo flo 70826188 Oct 3 17:10 Mail/inbox Ich verzichte gerne auf ein Bild des Cat contents dafür das ich mich nicht mit PLZ Polygonen rumärgere bei der geokodierung. 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
Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp
Am 3. Oktober 2013 17:12 schrieb Florian Lohoff f...@zz.de: PLZ ist ein Merkmal eines geografischen Zustellgebietes. Und sie ist in diesem Gebiet für alle Grundstücke gültig. Damit gibt es eine eindeutige Zuordnung PLZ -- Grundstück. Das alleine bestreite ich schon. Eine Postleitzahl ist ein Technisches Hilfsmittel der Deutschen Post um Gruppen von Adressen zu bilden. Diese hat den Zweck der einfachen überregionalen Logistik. Diese Gruppen wurden zum einen basierend auf der Geographischen lage aber eben auch nach anderen Kriterien erzeugt. +1, grundsätzlich gibt es zwar schon zusammenhängende Bereiche, aber es gibt halt auch viele Ausnahmen. Aber das ist wie mit maxspeeds. Um die wirklich sauber hinzubekommen mappe ich mittlerweile die Schilder der Geschwindigkeitsbeschränkungen, anders sind Asymmetrische maxspeeds nicht in den Griff zu bekommen. +1, den JOSM-Style für das Anzeigen der Schilder kennst Du vermutlich? Ausser für asymmetrische Limits hilft das Mappen der einzelnen Schilder auch zur Bestätigung bei unlogischen Limits, d.h. wenn in sehr kurzer Zeit das Limit sich ohne weiteren Grund mehrmals ändert (kommt in Deutschland so eher nicht vor), und es verhindert halbwegs, dass Straßenknoten an Stellen, wo sich das Limit ändert, aus Unachtsamkeit verschoben werden. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Normale Straße ?=mit =?utf-8?Q?area=yes
Am 3. Oktober 2013 16:50 schrieb Florian Lohoff f...@zz.de: Wenn der Way für die Straße darunter liegt halte ich das nicht für falsch - nur ungewohnt. naja, prinzipiell ist das m.E. gut, Straßen _auch_ als Fläche zu mappen, aber highway=residential mit area=yes ist problematisch (für gerichtete Verkehrsflächen sollte man den nicht verwenden). Auch könnte man mal darüber nachdenken, welche tags man an welches Objekt hängen will (name, surface, lit, etc.). Derzeit hat die Fläche diese tags: - area http://wiki.openstreetmap.org/wiki/Key:area?uselang=en = yes - area:highway = residential - highway http://wiki.openstreetmap.org/wiki/Key:highway?uselang=en = residentialhttp://wiki.openstreetmap.org/wiki/Tag:highway=residential?uselang=en - surface http://wiki.openstreetmap.org/wiki/Key:surface?uselang=en = asphalt Die Straße (highway) darunter hat diese tags: - bicycle http://wiki.openstreetmap.org/wiki/Key:bicycle?uselang=en = yes - foot http://wiki.openstreetmap.org/wiki/Key:foot?uselang=en = yes - highway http://wiki.openstreetmap.org/wiki/Key:highway?uselang=en = residentialhttp://wiki.openstreetmap.org/wiki/Tag:highway=residential?uselang=en - lit http://wiki.openstreetmap.org/wiki/Key:lit?uselang=en = yes - maxspeed http://wiki.openstreetmap.org/wiki/Key:maxspeed?uselang=en= 50 - name http://wiki.openstreetmap.org/wiki/Key:name?uselang=en = Otisstraße - parking:condition:both = free - parking:lane:both = parallel - postal_codehttp://wiki.openstreetmap.org/wiki/Key:postal%20code?uselang=en= 13403 - surface http://wiki.openstreetmap.org/wiki/Key:surface?uselang=en = asphalt Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID
Am 03.10.2013, 17:18 Uhr, schrieb Wolfgang Hinsch: Die Einstellung bei mir ist de-DE,en-US,en Die OSM-Webseite läuft komplett auf Deutsch. Der ID läuft komplett auf Englisch. Mit dieser Einstellung läuft bei mir (ebenfalls FF20) sowohl die OSM-Webseite als auch iD auf Englisch. Und das wäre gemäß deiner Einstellung im Prinzip auch nicht falsch (weil es keine Deutschland-Deutsche Übersetzung weder von der OSM-Webseite noch von iD gibt) und du explizit eingestellt hast, dass die generisches Deutsch-Übersetzung nicht verwendet werden soll. Unerklärbar ist mir aber wieso bei dir die Webseite trotzdem auf Deutsch läuft. Kann das sonst noch jemand nachvollziehen? Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Normale Straße ?=mit =?utf-8?Q?area=yes
On Thu, Oct 03, 2013 at 05:48:53PM +0200, Martin Koppenhoefer wrote: naja, prinzipiell ist das m.E. gut, Straßen _auch_ als Fläche zu mappen, aber highway=residential mit area=yes ist problematisch (für gerichtete Verkehrsflächen sollte man den nicht verwenden). Auch könnte man mal darüber nachdenken, welche tags man an welches Objekt hängen will (name, surface, lit, etc.). Derzeit hat die Fläche diese tags: Also bisher habe ich wenn ich groeße Verkehrs_flächen_ hatte die genau so getagged. D.h. highway=klasse-der-straße und dann area=yes. Normalerweise waren das bei mir Betriebshöfe etc so das das dann highway=service area=yes war. 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
Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp
On Thu, Oct 03, 2013 at 05:37:52PM +0200, Martin Koppenhoefer wrote: +1, den JOSM-Style für das Anzeigen der Schilder kennst Du vermutlich? Ja Ausser für asymmetrische Limits hilft das Mappen der einzelnen Schilder auch zur Bestätigung bei unlogischen Limits, d.h. wenn in sehr kurzer Zeit das Limit sich ohne weiteren Grund mehrmals ändert (kommt in Deutschland so eher nicht vor), und es verhindert halbwegs, dass Straßenknoten an Stellen, wo sich das Limit ändert, aus Unachtsamkeit verschoben werden. Ich kriege das auch ansonsten selber im Kopf nicht zusammen. Ich fahre ja oft nur teilbereiche irgendwelcher Straßen. Morgens hin - abends zurück. Abends kann ich micht nicht mehr Erinnern wo die Schilder in gegenrichtung Standen. 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
Re: [Talk-de] Gelöschte Linien finden und wieder herstellen
Super Idee Roland. Am Donnerstag, 3. Oktober 2013 schrieb Roland Olbricht : ein Server, der die gesamte Historie von OSM enthält und den Download der Daten eines (kleinen) Gebiets zu einem wählbaren Datum erlaubt, wäre für solche Probleme sehr nützlich. Damit könnte man auch die zeitliche Entwicklung eines Gebiets oder die Veränderungen durch ein Changeset visualisieren. Gibt es Überlegungen, so etwas einzurichten? Ich arbeite gerade daran, die Overpass API auch auf die Vergangenheit auszudehnen. Wird avoraussichtlich bis Weihnachten dauern. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org javascript:; 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] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp
Am Donnerstag, den 03.10.2013, 16:46 +0200 schrieb Jörg Frings-Fürst: [...] Ironie an Hallo, ich musste doch wieder einmal feststellen das ich immer noch dazu lerne: 1.) Eine Zuordnung PLZ -- Grundstück wird bestritten. 2.) Bis heute war ich der Meinung ein optimaler Weg Daten zu verarbeiten wäre das Vorhalten in einer Datenbank. Jetzt scheint es besser zu sein Daten auszulagern und zu komprimieren. zu 1.) Jetzt stellt sich für mich die Frage warum gibt es dann überhaupt PLZen? Und wie finden die Postsendungen den Empfänger? zu 2.) Ein Planet auf Disketten ist auch eine Möglichkeit. Nur wie lange würde das extrahieren nur von Deutschland dann dauern? Aber man könnte daraus einen neuen Beruf machen - Disk-Jockey ;) Ironie aus Hinweis an Die obrigen Punkte haben mich per PM erreicht, daher keine Möglichkeit zu zitieren. Hinweis aus Ich bleibe trotzdem der Meinung das die PLZ-Polygone nach Korrektur der bessere Weg sind PLZ zu erfassen. Und 19.000.000 Datensätze müssen in der Datenbank gespeichert, indiziert und verarbeitet werden. Und das kostet Zeit und Platz. Gute Nacht Jörg PS. Ich frage mich warum ich mir darüber Gedanken mache. Wo doch noch nicht einmal die administrativen Grenzen in Ordnung sind. Jörg -- Jörg Frings-Fürst OSM privat D-54526 Landscheid GPG Fingerprint: 13E3 4D4A 3228 D138 8511 EA5A 08AC AF02 3C6D 750A Full GPG key: hkp://pool.sks-keyservers.net CAcert Serialnr.: 0D:9A:23 SHA1-Fingerprint: CA:36:4D:44:D1:71:4A:78:C8:6C:C2:CC:94:F3:6E:42:38:BA:CE:4E http://cacert.org signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp
On Thu, Oct 03, 2013 at 09:26:12PM +0200, Jörg Frings-Fürst wrote: 1.) Eine Zuordnung PLZ -- Grundstück wird bestritten. Meine mail ging auch an die Liste wie du vielleicht feststellen konntest. Hier der Kontext: Jörg Frings-Fürst wrote PLZ ist ein Merkmal eines geografischen Zustellgebietes. Und sie ist in diesem Gebiet für alle Grundstücke gültig. Damit gibt es eine eindeutige Zuordnung PLZ -- Grundstück. Das alleine bestreite ich schon. Eine Postleitzahl ist ein Technisches Hilfsmittel der Deutschen Post um Gruppen von Adressen zu bilden. Diese hat den Zweck der einfachen überregionalen Logistik. Guck dir einfach mal die PLZ Polygone an und geh mal an den Rändern durch und such die Postleitzahlen mal auf der Webseite der Deutschen Post raus. Du wirst einige überraschungen erleben wo das gefundene so einfach mit Polygonen NICHT abbildbar ist es sein wir fangen jetzt auch mit en und exklaven an. Die Post benutzt keine Polygone sondern Adresslisten zur zuordnung der PLZ. Das das in kleinen Dörfern oft auf ein schönes einfach Polygon hinausläuft bestreite ich nicht. Das geht aber Orten mit mehr als einer PLZ schief. Dort hat man keine Polygone mehr sondern wenn es gut laeuft sieht das am ende aus wie ein Tintenfisch vielleicht aber auch eher wie Dalmatiner. Und ich habe schon diverses an PLZ polygonen versucht so hinzubiegen das das passt und an einigen stellen habe ich das einfach aufgegeben. 2.) Bis heute war ich der Meinung ein optimaler Weg Daten zu verarbeiten wäre das Vorhalten in einer Datenbank. Jetzt scheint es besser zu sein Daten auszulagern und zu komprimieren. Du hast damit argumentiert das es 380MByte sind die Postcode in Deutschland zusaetzlich zu erfassen. Ich habe gesagt das es sogar mehr ist - und wenn man es kompremiert auch gerne mal nur 18MByte. Nicht jedes byte im Planet muss und wird exakt so in der Datenbank stehen - Wir betreiben ja keinen geocoder auf dem planet als XML file sondern daten werden vorverarbeitet und dann nur extrakte die fuer diese aufgabe noetig sind in die Datenbank geschrieben. Wenn es nicht um OSM Daten gehen würde würde man sogar die Postleitzahlen in einer - und die Adressen in einer anderen tabelle halten - Relationales datenmodell und so ... Und 19.000.000 Datensätze müssen in der Datenbank gespeichert, indiziert und verarbeitet werden. Und das kostet Zeit und Platz. Diese aussage ist auch mal wieder spannend. Das hat doch ganz schwer was mit dem Schema zu tun. In einer mit osm2pgsql erzeugten datenbank stehen die GAR NICHT drin. Bei dem snapshot schema von osmosis sind sie nur ein attribut an einem node oder way in einem hstore. Damit sind sie kein eigenständiger Datensatz sondern vielleicht eine spalte wobei das bei hstore nichtmal eine eigenständige spalte ist. Wenn wir auf Nominatim eingehen berechnet dieser die Hierarchie ja vorab, d.h. selbst wenn ich keine PLZ eingebe ist die doch in der Datenbank. Und jetzt koennen wir nochmal die CPU und DiskIO kosten ausrechnen ob es sinn macht in einem varchar index zu suchen oder eben alle adressen via gist index der geometrien in der Datenbank gegen ein Multipolygon zu matchen. In dem einen Fall suche ich in einem index nach der Postleitzahl, im anderen Fall suche ich den gist index der Gebäudeumrisse bzw Nodes ob diese mit ST_Intersect via bounding box auf das extent eines Polygon matched. Den rest mache ich dann zu Fuß ohne Index. Ich tippe mal drauf das letzteres etwa 4-8 mal so viel CPU zeit braucht und vermutlich von der IO last faktor 2. Der IO Faktor könnte noch deutlich höher legen je nachdem welche geometrien alle in dem index stehen. Um es noch mal klar zu machen: Vorberechnen - Kein platzgewinn in der Datenbank So speichern - CPU intensiver bei der Abfrage. D.h. das einzige ueber was wir hier so reden sind die 18MByte die zusaetzlich im Planet file stehen. Der letzte Planet war 30GByte (http://planet.openstreetmap.org/planet/) bz2 XML. Wenn wir es dann mal schaffen alle PLZ in D zu erfassen haben wir da 18MByte mehr. Das sind 0.05% oder 0.5 Promille bei dem Planet von heute. Bis dahin wird der Planet vermutlich aber auch 100-200GByte haben und die paar Postleitzahlen sind - ähm - lächerlich. Flo PS: Ich propose highway demnaechst als hwy zu schreiben. Spart pro way in der Datenbank 4 byte - Macht bei 199406145 ways derzeit einen Gewinn von 760MByte - Oder nur h= - dann wären es 1.3GByte. building muesste dann b= sein - landuse ist l= - waterway ist w= --- Läuft. -- 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
Re: [Talk-de] Normale Straße mit area=yes
Wie bereits richtig gesagt ist das area:highway vollkommen in Ordnung, wird nur leider momentan noch nicht gerendert. Das highway-Tag hingegen muss da entfernt werden, denn der Weg darf nicht zum Routing benutzt werden, und das area=yes gehört demnach danach auch nicht mehr gesetzt. Ich habe übrigens vor kurzem ein Ticket zum Rendern von area:highway angelegt: http://github.com/gravitystorm/openstreetmap-carto/issues/180 Falls jemand in der Lage ist das mit voran zu treiben, wäre das super. Dann gäbe es auch keinen Grund mehr, in solchen Fällen Tags zu missbrauchen, und die Karte würde etwas hübscher aussehen. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID
Hallo, Am Donnerstag, den 03.10.2013, 19:02 +0200 schrieb Martin Raifer: Am 03.10.2013, 17:18 Uhr, schrieb Wolfgang Hinsch: Die Einstellung bei mir ist de-DE,en-US,en Die OSM-Webseite läuft komplett auf Deutsch. Der ID läuft komplett auf Englisch. Mit dieser Einstellung läuft bei mir (ebenfalls FF20) sowohl die OSM-Webseite als auch iD auf Englisch. Und das wäre gemäß deiner Einstellung im Prinzip auch nicht falsch (weil es keine Deutschland-Deutsche Übersetzung weder von der OSM-Webseite noch von iD gibt) und du explizit eingestellt hast, dass die generisches Deutsch-Übersetzung nicht verwendet werden soll. Unerklärbar ist mir aber wieso bei dir die Webseite trotzdem auf Deutsch läuft. Kann das sonst noch jemand nachvollziehen? Ich habe es noch einmal nachgeprüft. Die Webseite läuft komplett auf Deutsch, bis ich mich anmelde. Dann schaltet sie um auf Englisch. Da ich mich selten roh anmelde, hatte ich den Unterschied noch nicht bemerkt. echo $LANG de_DE.UTF-8 Das funktioniert in sämtlichen Programmen und allen Webseiten, bis auf OSM, wenn ich mich anmelde. de_DE ist Posix-Konform, siehe http://de.wikipedia.org/wiki/Locale Alternativ wäre de_AT für Österreich. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID
Am Freitag, den 04.10.2013, 01:21 +0200 schrieb Wolfgang Hinsch: Das funktioniert in sämtlichen Programmen und allen Webseiten, bis auf OSM, wenn ich mich anmelde. Nachtrag: Auch JOSM läuft problemlos auf Deutsch. Gruß, d.o. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schienen mit abandoned
Am 03.10.2013 10:06, schrieb Bernhard Kuisle: Hallo fly, danke für die freundliche Antwort. Lese nun seit ca. 1 Monat mit und weiss, dass das der übliche Umgangston hier ist. Aber wie wäre es mit nachschauen? Es handelt sich hier um eine ehemalige Bahnstrecke, die seit ca. 30 Jahren stillgelegt ist und eben bis auf zerfallene Brücken und den Schotteruntergrund fast nichts mehr da ist und wo jetzt eine meist ortsnahe Radstrecke eröffnet wurde. Ist mir jetzt zwar nicht ganz klar um was es hier genau geht - aber ein rechtlicher Hinweis zu Bahnstrecken (in Deutschland) scheint mir hier angebracht: Es gilt zu unterscheiden zwischen stillgelegten und entwidmeten Strecke. Beiden gemeinsam ist das kein regulärer Bahnverkehr mehr stattfindet. Über den baulichen Zustand kann damit aber keine sichere Aussage getroffen werden. Beide können physikalisch noch befahrbar sein oder soweit abgebaut und überwuchert sein dass der ehemalige Bahnverkehr zumindest für den Laien nicht mal mehr erahnbar ist. Der Unterschied besteht darin, dass eine stillgelegte Strecke jederzeit wieder als Bahnstrecke in Betrieb genommen werden kann, auch wenn dazu erhebliche bauliche Aufwendungen nötig sind. Es ist aber nach wie vor ein Bahngelände das für eine eventuelle Wiederinbetriebnahme bereitgehalten werden muss und nicht verbaut werden darf (Es soll wohl auch Fälle geben in denen mehr oder weniger widerrechtlich Radwege angelegt wurden)! Entwidmete Strecken werden baurechtlich dagegen so behandelt wie wenn noch nie eine Strecke vorhanden gewesen wäre (Planfeststellungsverfahren etc. für eine Wiederinbetriebnahme erforderlich). Dennoch kann auf einer entwidmeten Strecke noch eine Gleisanlage vorhanden sein und z.B. für touristische Zwecke ein Fahrrad-Draisinenbetrieb stattfinden. Leider wird das Thema in OSM sehr stiefmütterlich behandelt - das Löschen einer lediglich stillgelegten Bahntrasse (auch wenn keine Gleisanlagen mehr zu sehen/vorhanden sind) sehe ich als Vandalismus an! Garry ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID
Wolfgang Hinsch schrieb: Ich habe es noch einmal nachgeprüft. Die Webseite läuft komplett auf Deutsch, bis ich mich anmelde. Dann schaltet sie um auf Englisch. Dass du auf https://www.openstreetmap.org/user/USERNAME/account im Abschnitt „Bevorzugte Sprachen“ eben diese z.B. mit „de“ (konform nach ISO 3166-1) festlegen kannst, weißt du aber, oder? Grüße, Dirk -- Local time :: Ortszeit :: DE-HH 2013-10-04T06:39:22+0200 signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp
Moin, Am Donnerstag, den 03.10.2013, 17:02 +0200 schrieb Florian Lohoff: Hola, [...] Hierzu: wie kann man denn eine verlässliche Datenquelle für die PLZ Gebiete bekommen? Es gibt keine - Ich glaube nicht das die Deutsche Post stand heute Polygone hat. Ich glaube auch nicht das irgendjemand wirklich mit den Polygonen arbeitet um absolut korrekte informationen zu erarbeiten. ZitatGeocodierte Flächen weisen die Postleitzahlgebiete in Deutschland sowie die Leitregionen und Leitzonen aus /Zitat [1] Gruß Jörg [1] http://www.deutschepost.de/dpag?tab=1skin=hicheck=yeslang=de_DExmlFile=link1020331_1020325 -- Jörg Frings-Fürst OSM privat D-54526 Landscheid GPG Fingerprint: 13E3 4D4A 3228 D138 8511 EA5A 08AC AF02 3C6D 750A Full GPG key: hkp://pool.sks-keyservers.net CAcert Serialnr.: 0D:9A:23 SHA1-Fingerprint: CA:36:4D:44:D1:71:4A:78:C8:6C:C2:CC:94:F3:6E:42:38:BA:CE:4E http://cacert.org signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] Alcuni articoli Wikipedia mappabili in OSM
Grande Simone! Quello che tu dici e' esattamente uno dei motivi su cui Cristian ed io ci siamo interrogati. Siamo anche in contatto con l'autore dell'estensione di Mediawiki che visualizza le mappe. Cristian ha presentato a State of The Map le cose su cui sta lavorando http://lanyrd.com/2013/sotm/scpkrc/ Un vero peccato che tu non ci sia a OSMIT perche' il tuo lavoro sarebbe da presentare. Cerchiamo pero' il modo di valorizzare il piu' possibile questi lavori e di unirli PS: hai intenzione di rilasciare il codice del tuo script? 2013/10/2 Simone F. grop...@gmail.com: Ciao a tutti. Per chi non lo sapesse, gli articoli Wikipedia taggati in OpenStreetMap mostrano l'oggetto su una mappa. Vedi: Colosseo http://i.imgur.com/HNE9RCJ.png Lago di Garda http://i.imgur.com/qD8SjPI.png Quando ho letto che la collaborazione Wikipedia - OSM sarebbe stato uno degli argomenti di OSMIT (a cui purtroppo, come ho scritto, non posso andare) ho ripreso un programma che avevo lasciato a metà, tempo fa. Il programma crea delle liste di articoli riguardanti oggetti mappabili (palazzi, laghi, autostrade, rifugi alpini, aree protette, monumenti, stadi, piazze...), per individuare quelli ancora da taggare in OSM. http://dl.dropboxusercontent.com/u/41550819/OSM/WTOSM/html/index.html Sarebbe bello riuscire a completare almeno una categoria e, a chi vuole aggiungere dei tag, io propongo: Laghi d'Italia :) Seguono altre informazioni, per chi non è ancora stanco di leggere. Dai i link si può: - vedere come sono stati mappati luoghi importanti, scaricandoli in JOSM o visitando le loro pagine OSM - vedere gli oggetti di una categoria sulle mappe cliccabili di Overpass Turbo (il link compare passando con il mouse sopra il nome della cateogria). Difetti: - articoli o sottocategorie appartenenti a più categorie sono ripetuti più volte nella stessa pagina - nel caso usiate le pagine, vi sarei grato se mi segnalaste, oltre agli inevitabili bug, eventuali articoli e categorie non mappabili (ad es. Dipinti nel museo Tal Dei Tali, Elenco dei teatri di Vattelappesca) così da poterli nascondere. Lo script, in Python, utilizza: osmconvert/update/filter e lxml per i dati OSM, ed interroga catscan e le API Wikipedia per ottenere i nomi di categorie ed articoli. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Utenti che importano con errori
Sto cercando di eseguire il revert degli edits di AlfiusMSA, partendo dal piu' recente ed andando a ritroso. Purtroppo JOSM si inchioda e non mi fa proseguire... :-( Ho aperto un ticket: http://josm.openstreetmap.de/ticket/9151 Qualche suggerimento? Ciao /niubii/ Il giorno 02 ottobre 2013 23:43, Leonardo kinetocor...@gmail.com ha scritto: Se serve una mano per questi import, fatemi un fischio, qualche informazione in più posso dargliela io, soprattutto per la pre-pulizia e import dei dati. Ciao! Leonardo Il 02/10/2013 22:53, Martin Koppenhoefer ha scritto: 2013/10/2 Francesco Pelullo f.pelu...@gmail.com L'utente mi scriveva di aver eseguito degli import senza conoscere in dettaglio OSM, e di essere disponibile a cancellare tutto. Adesso bisognerebbe verificare se queste geometrie sono tutte alla versione 1 (e quindi eliminabili senza troppi rimpianti) oppure se qualcun altro ci ha già messo mano, ad esempio l'utente studiovega. Qualcuno ha una ricetta veloce per fare questa verifica? si, sembra caso chiaro (revert), anche perché ha caricato sopra le cose già esistenti. Se te la senti puoi fare il revert, altrimenti chiederei al più presto alla DWG, perché più tempo che passa (e modifiche che vengono fatte) più laborioso è il revert. ciao, Martin ___ Talk-it mailing listTalk-it@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Utenti che importano con errori
Il giorno 03 ottobre 2013 10:56, Francesco Pelullo f.pelu...@gmail.com ha scritto: Sto cercando di eseguire il revert degli edits di AlfiusMSA, partendo dal piu' recente ed andando a ritroso. Purtroppo JOSM si inchioda e non mi fa proseguire... :-( Ho aperto un ticket: http://josm.openstreetmap.de/ticket/9151 Qualche suggerimento? Io sto usando questi quando faccio i revert http://wiki.openstreetmap.org/wiki/Revert_scripts Ciao /niubii/ Ciao, Stefano ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Marciapiedi
Mario Pichetti wrote La mia era solo una prova. Se non servono li elimino (i marciapiedi), oppure devo aggiungere i tag della SP302 (primary o secondary ?). Ciao Mario È questo il punto...non servono a chi? ai disabili? alle persone con piene capacità motorie? non è che solo loro utilizzano la mappa!Ci sono un infinità di elementi mappati e che non servono assolutamente a nulla per il routing. Perchè a questo punto dovremmo mappare ogni singolo campo? Alla maggior parte delle persone interessa sapere che quella data area è adibita a scopo agricolo, non la grandezza e l'orientamento dei singoli campi. Eppure mappiamo anche i singoli campi perchè potrebbe servire. Lo stesso dicasi per i percorsi pedonali mappati separatamente (che insisto ha valenza anche dal punto di vista del routing visto che per alcuni aspetti importanti è più preciso IMHO), anche perchè su di essi possono essere fatti calcoli precisi per quanto riguarda le distanze medie percorse dai pedoni ed intralcio tra i flussi di pedoni (quindi con possibili ripercussioni su studi urbanistici, studi di mobilità o anche solo per gli atleti come già detto). Il motivo che IMHO aveva più senso per essere contrari a questo tipo di mappatura è il fatto che costringa a fare giri più lunghi per attraversare la strada...purtroppo però abbiamo visto come l'attraversare fuori dalle strisce sia VIETATO entro 100m da queste (e in città è rara una distanza del genere tra le strisce) e siccome il routing che sfrutta i tag sidewalk=left/right/both non fa assolutamente alcuna valutazione del attraversamento direi che IMHO questo sia un difetto ben più grave del eventualità di far allungare la strada (che comunque il pedone può decidere di accorciare attraversando dove ritiene più opportuno, ma a proprio rischio e pericolo) o di non dire il nome della way Quindi in definitiva no! Se ci sono già le way separate è meglio che le lasci. In questo caso, visto che non ci sono differenze in base a cui adottare uno stile di mappatura rispetto ad un altro, scegli lo stile di mappatura che vuoi in base al tempo che puoi dedicare. Inoltre considera anche che: 1)la mappatura con way separate è più esplicita dal punto di vista visivo rispetto ad un tag (invisibile...anche nel routing dove both/left/right ad ora non influenza assolutamente il calcolo del percorso) e, anche se non mappiamo per il render, secondo me questo è un punto a favore visto che facilita l'identificazione di incongruenze/inesattezze. 2)per quanto concerne il fatto che i marciapiedi così mappati, se non hanno assegnato il nome, diano problemi con le indicazioni, teoricamente questo è un difetto dei programmi di routing compensabile (ne parlano nel wiki e comunque basterebbe ripetere il tag name al marciapiede o creare una relation tra questo e la strada ) e comunque è solo un problema di nome...le indicazioni svolta a destra, svolta a sinistra, attraversa vengono date ugualmente e per queste sono anche più precise che assegnando semplicemente il tag sidewalk=* alla strada. 3) Questo stile di mappatura ha cominciato a venire adottato di recente ma ha già raggiunto un numero di elementi mappati in questa maniera pari a circa la metà della somma dei tag sidewalk=left/right/both 4) Si sta cominciando a proporre da sempre più tempo l'idea dell'utilizzo del tag area:highway=* che naturalmente prevede che strade e marciapiedi vengano mappate separatamente ognuno con la propria relativa area attorno con tag area:highway= , come si può vedere qui[1] Stile di tagging questo che, nonostante sia estremamente avanzato e lungo(quindi effettuato solo da mappatori esperti che probabilmente usano JOSM o Merkaartor) , è già parecchio utilizzato come puoi notare qui [2] 5) una strada con la mappatura tramite tagging deve venir divisa ogni volta che lungo il suo percorso cambiano delle condizioni (e quindi dei valori dei tag). L'aggiungere la condizione della presenza di un marciapiede aggiunge una o più possibili variabili (dipende da quanto precisamente vuoi descrivere il marciapiede...più la descrizione è precisa + tag si useranno) che potenzialmente potrebbe costringere ulteriori divisioni. Con la mappatura separata teoricamente il marciapiede verrebbe diviso solo la dove cambino i valori del marciapiede e la strada solo la dove cambiano i valori della strada. secondo me più ordinato, più intuitivo e facile da capire anche per i nuovi mappatori in generale su osm qualsiasi cosa mappata correttamente è/potrebbe essere utile. scegli secondo le tue capacità/possibilità. quei marciapiedi separati, se mappati correttamente, quindi sono utili. [1]http://wiki.openstreetmap.org/wiki/Key:area:highway [2]http://taginfo.openstreetmap.org/search?q=area%3Ahighway - Ciao, Aury -- View this message in context: http://gis.19327.n5.nabble.com/Marciapiedi-tp5779379p5779888.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list
Re: [Talk-it] Utenti che importano con errori
In questo caso, ti cederei volentieri questa incombenza! :-) Scherzi a parte, visto che hai sicuramente più esperienza di me, se ti va di eseguire i revert, fai pure. Ciao /niubii/ Il giorno 03 ottobre 2013 11:01, sabas88 saba...@gmail.com ha scritto: Il giorno 03 ottobre 2013 10:56, Francesco Pelullo f.pelu...@gmail.comha scritto: Sto cercando di eseguire il revert degli edits di AlfiusMSA, partendo dal piu' recente ed andando a ritroso. Purtroppo JOSM si inchioda e non mi fa proseguire... :-( Ho aperto un ticket: http://josm.openstreetmap.de/ticket/9151 Qualche suggerimento? Io sto usando questi quando faccio i revert http://wiki.openstreetmap.org/wiki/Revert_scripts Ciao /niubii/ Ciao, Stefano ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Alcuni articoli Wikipedia mappabili in OSM
Il giorno 03 ottobre 2013 09:40, Maurizio Napolitano napoo...@gmail.comha scritto: Grande Simone! ... Cristian ha presentato a State of The Map le cose su cui sta lavorando http://lanyrd.com/2013/sotm/scpkrc/ Grazie. Non sapevo del lavoro di Cristian. Cerchiamo pero' il modo di valorizzare il piu' possibile questi lavori e di unirli PS: hai intenzione di rilasciare il codice del tuo script? Sì, il link è già sulla pagina... ;-) vedi in alto: Informazioni e conteggi. La parte di analisi dei dati (OSM e Wikipedia) e la creazione delle pagine web sono separate. Se qualcuno vuole riutilizzare parti dello script o ha delle domande, rispondo molto volentieri. Aggiornerò le pagine manualmente. Se dovessero rivelarsi utili, sarei felice se qualcuno ospitasse lo script su un server, per eseguirlo regolarmente (le dipendenze sono minime, vedi README). Ciao, Simone F. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Marciapiedi
2013/10/3 Aury88 spacedrive...@gmail.com È questo il punto...non servono a chi? ai disabili? alle persone con piene capacità motorie? non è che solo loro utilizzano la mappa!Ci sono un infinità di elementi mappati e che non servono assolutamente a nulla per il routing. +1, sono d'accordo con te, la domanda a cosa serve non si pone, e chi vuole può mappare qualsiasi cosa (al meno non sia qualcosa come un evento singolo ecc.). Non vorrei introdurre dei criterei di rilevanza, anzi mi oppongo proprio. Il mio è più un discorso che dico i marciapiedi sono compresi nella strada come lo sono le corsie. Se vuoi mappare corsie, ben venga, ma non come singoli highway. Perché mappare marciapiedi con 2 tags (highway=footway, footway=sidewalk) invece di un solo tag: footway=sidewalk? ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Estratti regionalidi FMACH
2013/9/26 Cristian Consonni kikkocrist...@gmail.com: (separo il thread per comodità) Ciao, ciao come consigliato da Luca, mi sono scaricato ital.img[1] e osmconvert[2a][2b] ed ho fatto un po' di prove. L'unica modifica che ho apportato è sostituire: italy.osm.bz2 con italy-latest.osm.bz2, ho scaricato il file da geofabrik e ho lanciato lo script così: ./italimg.sh -f -R regione regione.out grazie per aver testato, ho fatto le modifiche suggerite. Ho modificato il file da scaricare, ora è una variabile e aggiunto un file che per ora elimina e scarica osmconvert, in seguito dovrebbe essere in grado di aggiornare anche mkgmap e splitter (se riesco lo faccio oggi) A breve lancio lo script per aggiornare speriamo non dia problemi -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Estratti regionalidi FMACH
2013/10/3 Luca Delucchi lucadel...@gmail.com: 2013/9/26 Cristian Consonni kikkocrist...@gmail.com: (separo il thread per comodità) Ciao, ciao come consigliato da Luca, mi sono scaricato ital.img[1] e osmconvert[2a][2b] ed ho fatto un po' di prove. L'unica modifica che ho apportato è sostituire: italy.osm.bz2 con italy-latest.osm.bz2, ho scaricato il file da geofabrik e ho lanciato lo script così: ./italimg.sh -f -R regione regione.out grazie per aver testato, ho fatto le modifiche suggerite. Ho modificato il file da scaricare, ora è una variabile e aggiunto un file che per ora elimina e scarica osmconvert, in seguito dovrebbe essere in grado di aggiornare anche mkgmap e splitter (se riesco lo faccio oggi) A breve lancio lo script per aggiornare speriamo non dia problemi Anche se mi ha dato questi warning sembra andare file aggiornati a ieri pomeriggio, fra un paio di ore saranno sul sito in download stdin: In function ‘cww__flush’: stdin:6177:8: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result] stdin: In function ‘cwn__flush’: stdin:6046:8: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result] stdin: In function ‘rr__flush’: stdin:5919:8: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result] stdin: In function ‘posr__flush’: stdin:5638:8: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result] stdin: In function ‘assistant’: stdin:11032:9: warning: ignoring return value of ‘fgets’, declared with attribute warn_unused_result [-Wunused-result] stdin:11044:9: warning: ignoring return value of ‘fgets’, declared with attribute warn_unused_result [-Wunused-result] stdin:11072:3: warning: ignoring return value of ‘fgets’, declared with attribute warn_unused_result [-Wunused-result] stdin:11084:5: warning: ignoring return value of ‘fgets’, declared with attribute warn_unused_result [-Wunused-result] stdin:0:5: warning: ignoring return value of ‘fgets’, declared with attribute warn_unused_result [-Wunused-result] stdin:11165:7: warning: ignoring return value of ‘fgets’, declared with attribute warn_unused_result [-Wunused-result] stdin:11186:7: warning: ignoring return value of ‘fgets’, declared with attribute warn_unused_result [-Wunused-result] stdin:11211:7: warning: ignoring return value of ‘fgets’, declared with attribute warn_unused_result [-Wunused-result] stdin:11213:7: warning: ignoring return value of ‘fgets’, declared with attribute warn_unused_result [-Wunused-result] stdin:11215:7: warning: ignoring return value of ‘fgets’, declared with attribute warn_unused_result [-Wunused-result] stdin:11217:7: warning: ignoring return value of ‘fgets’, declared with attribute warn_unused_result [-Wunused-result] stdin:11231:7: warning: ignoring return value of ‘fgets’, declared with attribute warn_unused_result [-Wunused-result] -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Alcuni articoli Wikipedia mappabili in OSM
2013/10/2 Simone F. grop...@gmail.com: Ciao a tutti. Ciao Per chi non lo sapesse, gli articoli Wikipedia taggati in OpenStreetMap mostrano l'oggetto su una mappa. Vedi: Colosseo http://i.imgur.com/HNE9RCJ.png Lago di Garda http://i.imgur.com/qD8SjPI.png Quando ho letto che la collaborazione Wikipedia - OSM sarebbe stato uno degli argomenti di OSMIT (a cui purtroppo, come ho scritto, non posso andare) ho ripreso un programma che avevo lasciato a metà, tempo fa. Il programma crea delle liste di articoli riguardanti oggetti mappabili (palazzi, laghi, autostrade, rifugi alpini, aree protette, monumenti, stadi, piazze...), per individuare quelli ancora da taggare in OSM. http://dl.dropboxusercontent.com/u/41550819/OSM/WTOSM/html/index.html bello Sarebbe bello riuscire a completare almeno una categoria e, a chi vuole aggiungere dei tag, io propongo: Laghi d'Italia :) già aggiunti alcuni Ciao, Simone F. (Groppo, sul Wiki) -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Alcuni articoli Wikipedia mappabili in OSM
C'è anche un addon per Josm usando i dati di Wikipedia per taggare gli oggetti OSM. Ci sono qualchi informazioni sulla pagina wiki del progetto WIWOSM. http://wiki.openstreetmap.org/wiki/WIWOSM Florian.___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Estratti regionalidi FMACH
2013/10/3 Luca Delucchi lucadel...@gmail.com: ./italimg.sh -f -R regione regione.out grazie per aver testato, ho fatto le modifiche suggerite. Ho modificato il file da scaricare, ora è una variabile e aggiunto un file che per ora elimina e scarica osmconvert, in seguito dovrebbe essere in grado di aggiornare anche mkgmap e splitter (se riesco lo faccio oggi) A breve lancio lo script per aggiornare speriamo non dia problemi non è che nella toolchain hai qualcosa a 32bit che quindi killa i nodi recenti? -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Marciapiedi
Il mio è più un discorso che dico i marciapiedi sono compresi nella strada come lo sono le corsie. Se vuoi mappare corsie, ben venga, ma non come singoli highway. Potrei dire che il mappare tutte le corsie con una sola way lo si fa perchè è possibile passare da una corsia all'altra a riprova del perchè le mappiamo con un unica way secondo me è utile valutare in che casi in cui noi non lo facciamo cioè dove si frappone tra una corsia e l'altra un ostacolo fisico. con questi criteri secondo me diventa lecito mappare i marciapiedi rialzati separatamente. (ricordo che se è presente il marciapiede ai pedoni è vietato occupare la carreggiata mentre teoricamente alle macchine sarebbe vietato parcheggiare o circolare sui marciapiedi di fatto con questa regola il traffico pedonale rimane segregato dal traffico veicolare quindi una separazione giuridica oltre che fisica) questa cosa poi del mappare le corsie in un unica way non è propriamente vera e sei stato tu stesso in una discussione tempo fa sui caselli autostradali a dare parere positivo alla mappatura delle singole corsie per i singoli caselli anche prima degli stessi, cioè laddove non sussiste ancora alcuna separazione fisica tra le varie corsie. cioè |macchina||macchina||macchina| in questo caso vengono mappate la propria way mentre |macchina||pedoni| dovrebbero avere un unica way? Perché mappare marciapiedi con 2 tags (highway=footway, footway=sidewalk) invece di un solo tag: footway=sidewalk? perchè amenity=restaurant, cousine=italian e non restaurant=italian? perchè historic=archaeological_site site_type=megalith e non historic=megalith? Usiamo una struttura di tag ad albero. il tag più importante da una descrizione generica per distinguere a che macro-categoria appartiene l'elemento, i successivi tag specificano meglio le caratteristiche dell'oggetto. Un po come avviene in biologia con la classificazione scientifica (Dominio, Regno, Phylum Classe, Ordine, Famiglia, Genere, Specie) ps: da notare la foto ed il tag posto sotto nel wiki [1] che è la stessa di sidewalk[2] questo per bredy e il suo dubbio sulla differenza degli elementi: nessuna! la differenza sta solo nello stile di mappatura del mappatore ma fisicamente le due cose sono equivalenti. io preferisco mappare i marciapiedi rialzati separatamente e se non si sono, ma sono presenti delle banchine sufficientemente larghe per il passaggio pedonale, usare il tag sidewalk=left/right/both. [1] http://wiki.openstreetmap.org/wiki/Key:footway [2] http://wiki.openstreetmap.org/wiki/Key:sidewalk - Ciao, Aury -- View this message in context: http://gis.19327.n5.nabble.com/Marciapiedi-tp5779379p5779930.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] Marciapiedi
2013/10/3 Aury88 spacedrive...@gmail.com a riprova del perchè le mappiamo con un unica way secondo me è utile valutare in che casi in cui noi non lo facciamo cioè dove si frappone tra una corsia e l'altra un ostacolo fisico. con questi criteri secondo me diventa lecito mappare i marciapiedi rialzati separatamente. e poi che fai, metti foot=no alla strada? ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] F4 Map
Ciao a tutti, per chi ancora non l'avesse visto vi consiglio di dare un'occhiata a http://map.f4-group.com/ Contiene contenuti non del tutto liberi ed è ancora agli albori (è nato a giugno), ma tra tutti i 3D-OSM che ho visto questo è quello con il miglior rapporto leggerezza/completezza. Lorenzo ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Estratti regionalidi FMACH
2013/10/3 Simone Cortesi sim...@cortesi.com: non è che nella toolchain hai qualcosa a 32bit che quindi killa i nodi recenti? ha finito e mi sembra correttamente FEM:~/github/ital.img$ ./osmconvert --statistics /var/www/gfoss_geodata/osm/output_osm_regioni/veneto.pbf /dev/null timestamp min: 2006-06-30T11:51:33Z timestamp max: 2013-10-02T19:01:12Z lon min: 10.5507941 lon max: 13.1769444 lat min: 44.7837933 lat max: 46.7375416 nodes: 19199114 ways: 2567599 relations: 13851 node id min: 9191978 node id max: 2480408573 way id min: 4045604 way id max: 240302224 relation id min: 8569 relation id max: 3241013 keyval pairs max: 259 keyval pairs max object: relation 365331 noderefs max: 1893 noderefs max object: way 58757325 relrefs max: 3639 relrefs max object: relation 2577916 -- -S -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Estratti regionalidi FMACH
2013/10/3 Luca Delucchi lucadel...@gmail.com: FEM:~/github/ital.img$ ./osmconvert --statistics /var/www/gfoss_geodata/osm/output_osm_regioni/veneto.pbf /dev/null timestamp min: 2006-06-30T11:51:33Z timestamp max: 2013-10-02T19:01:12Z ho provato a scaricare la lombardia, chiedendo il link nella pagina: http://geodati.fmach.it/gfoss_geodata/osm/italia_osm.html mi da errore simone@blackmagic:~/develop/ital.img$ wget http://geodati.fmach.it/gfoss_geodata/osm/output_osm_regioni/lombardia.pbf --2013-10-03 16:40:56-- http://geodati.fmach.it/gfoss_geodata/osm/output_osm_regioni/lombardia.pbf Resolving geodati.fmach.it (geodati.fmach.it)... 77.72.197.167 Connecting to geodati.fmach.it (geodati.fmach.it)|77.72.197.167|:80... connected. HTTP request sent, awaiting response... 403 Forbidden 2013-10-03 16:40:57 ERROR 403: Forbidden. -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] F4 Map
Altra cosa fantastica è che prende anche le informazioni meteo. Quindi, se piove, appare l'animazione della pioggia. Oltre a questo prende in considerazione anche la luce e la direzione dell'ombra. 2013/10/3 Lorenzo Beba Beltrami lorenzo.b...@gmail.com: Mi hanno detto che a giorni implementeranno anche navi e traghetti. Sono già correttamente renderizzati le building:part, i colori e i materiali degli edifici, i vari roof, le tombe nei cimiteri, i tipi di barrier, le gru nei landuse=construction, i tralicci e i pali assieme al numero di cavi elettrici, e tanto altro... E' un po' un giocattolo, ma l'effetto finale è esteticamente appagante. Inoltre la mappa viene aggiornata ogni 5 minuti. Lorenzo Il giorno 03 ottobre 2013 16:16, Maurizio Napolitano napoo...@gmail.com ha scritto: e aggiungo che da poco ha anche aggiunto la possibilità di visualizzare anche il modello digitale del terreno 2013/10/3 Lorenzo Beba Beltrami lorenzo.b...@gmail.com: Ciao a tutti, per chi ancora non l'avesse visto vi consiglio di dare un'occhiata a http://map.f4-group.com/ Contiene contenuti non del tutto liberi ed è ancora agli albori (è nato a giugno), ma tra tutti i 3D-OSM che ho visto questo è quello con il miglior rapporto leggerezza/completezza. Lorenzo ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it -- Maurizio Napo Napolitano http://de.straba.us ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it -- Maurizio Napo Napolitano http://de.straba.us ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Estratti regionalidi FMACH
2013/10/3 Simone Cortesi sim...@cortesi.com: 2013/10/3 Luca Delucchi lucadel...@gmail.com: FEM:~/github/ital.img$ ./osmconvert --statistics /var/www/gfoss_geodata/osm/output_osm_regioni/veneto.pbf /dev/null timestamp min: 2006-06-30T11:51:33Z timestamp max: 2013-10-02T19:01:12Z ho provato a scaricare la lombardia, chiedendo il link nella pagina: http://geodati.fmach.it/gfoss_geodata/osm/italia_osm.html mi da errore simone@blackmagic:~/develop/ital.img$ wget http://geodati.fmach.it/gfoss_geodata/osm/output_osm_regioni/lombardia.pbf --2013-10-03 16:40:56-- http://geodati.fmach.it/gfoss_geodata/osm/output_osm_regioni/lombardia.pbf Resolving geodati.fmach.it (geodati.fmach.it)... 77.72.197.167 Connecting to geodati.fmach.it (geodati.fmach.it)|77.72.197.167|:80... connected. HTTP request sent, awaiting response... 403 Forbidden 2013-10-03 16:40:57 ERROR 403: Forbidden. mancavano dei permessi... ora va -- -S -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Estratti regionalidi FMACH
On Thu, Oct 3, 2013 at 5:05 PM, Luca Delucchi lucadel...@gmail.com wrote: mancavano dei permessi... ora va grazie, 10 minuti e ti so dire il risultato di osmconvert -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Problemi con generate_xml.py in mapnik
Per completezza un follow-up: sto indagando e il problema non è (penso) nel upgrade di ubuntu ma nel upgrade di mapnik a 2.2. Tutta la parte rilevante viene fatta con i python bindings di mapnik (mapnik.save_map). ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Alcuni articoli Wikipedia mappabili in OSM
2013/10/3 Simone F. grop...@gmail.com: Aggiornerò le pagine manualmente. Se dovessero rivelarsi utili, sarei felice se qualcuno ospitasse lo script su un server, per eseguirlo regolarmente (le dipendenze sono minime, vedi README). l'ho provato e ho dato un'occhiata al codice (mi sembra veramente scritto bene), con un po' di maggior controllo al launch_script.py e ho alcune domande e suggerimenti: - primo potremmo mettere il codice in qualche repository in modo da lavorarci con più facilità? - io lascerei il nome completo del file pbf uguale a quello di scaricamento oppure avere due variabili diverse (aiuterebbe a non dover copiare il file se già presente con altri per altri programmi) - avere un install che controlla le varie dipendenze e le installa se mancano (posso farlo io) comunque ho fatto il download ma poi mi è uscito questo errore ./italy.o5m ./italy.o5m assente - Filtra i dati OSM con tag wikipedia osmfilter Error: could not open input file: ./italy.o5m sembra che non entri nella funzione convert_pbf_to_o5m Ciao, Simone F. -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Alcuni articoli Wikipedia mappabili in OSM
Il 02/10/2013 23:06, Simone F. ha scritto: Ciao a tutti. Per chi non lo sapesse, gli articoli Wikipedia taggati in OpenStreetMap mostrano l'oggetto su una mappa. Vedi: Colosseo http://i.imgur.com/HNE9RCJ.png Lago di Garda http://i.imgur.com/qD8SjPI.png Quando ho letto che la collaborazione Wikipedia - OSM sarebbe stato uno degli argomenti di OSMIT (a cui purtroppo, come ho scritto, non posso andare) ho ripreso un programma che avevo lasciato a metà, tempo fa. Un vero peccato che tu non possa partecipare, cosi perdi le birre:-) Il programma crea delle liste di articoli riguardanti oggetti mappabili (palazzi, laghi, autostrade, rifugi alpini, aree protette, monumenti, stadi, piazze...), per individuare quelli ancora da taggare in OSM. http://dl.dropboxusercontent.com/u/41550819/OSM/WTOSM/html/index.html Capperi, sono esterefatto, di questo passo inventerai un droide che mappa automaticamente. Sarebbe bello riuscire a completare almeno una categoria e, a chi vuole aggiungere dei tag, io propongo: Laghi d'Italia :) OK, vada per i laghi, ne abbiamo di bellissimi. Seguono altre informazioni, per chi non è ancora stanco di leggere. Dai i link si può: - vedere come sono stati mappati luoghi importanti, scaricandoli in JOSM o visitando le loro pagine OSM - vedere gli oggetti di una categoria sulle mappe cliccabili di Overpass Turbo (il link compare passando con il mouse sopra il nome della cateogria). Difetti: - articoli o sottocategorie appartenenti a più categorie sono ripetuti più volte nella stessa pagina - nel caso usiate le pagine, vi sarei grato se mi segnalaste, oltre agli inevitabili bug, eventuali articoli e categorie non mappabili (ad es. Dipinti nel museo Tal Dei Tali, Elenco dei teatri di Vattelappesca) così da poterli nascondere. Lo script, in Python, utilizza: osmconvert/update/filter e lxml per i dati OSM, ed interroga catscan e le API Wikipedia per ottenere i nomi di categorie ed articoli. Ciao, Simone F. (Groppo, sul Wiki) ___ Conserverò con cura questa mail, grazie, Mario. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Marciapiedi
Il 03/10/2013 11:30, Aury88 ha scritto: Mario Pichetti wrote La mia era solo una prova. Se non servono li elimino (i marciapiedi), oppure devo aggiungere i tag della SP302 (primary o secondary ?). Ciao Mario È questo il punto...non servono a chi? ai disabili? alle persone con piene capacità motorie? non è che solo loro utilizzano la mappa!Ci sono un infinità di elementi mappati e che non servono assolutamente a nulla per il routing. Perchè a questo punto dovremmo mappare ogni singolo campo? Alla maggior parte delle persone interessa sapere che quella data area è adibita a scopo agricolo, non la grandezza e l'orientamento dei singoli campi. Eppure mappiamo anche i singoli campi perchè potrebbe servire. Lo stesso dicasi per i percorsi pedonali mappati separatamente (che insisto ha valenza anche dal punto di vista del routing visto che per alcuni aspetti importanti è più preciso IMHO), anche perchè su di essi possono essere fatti calcoli precisi per quanto riguarda le distanze medie percorse dai pedoni ed intralcio tra i flussi di pedoni (quindi con possibili ripercussioni su studi urbanistici, studi di mobilità o anche solo per gli atleti come già detto). Il motivo che IMHO aveva più senso per essere contrari a questo tipo di mappatura è il fatto che costringa a fare giri più lunghi per attraversare la strada...purtroppo però abbiamo visto come l'attraversare fuori dalle strisce sia VIETATO entro 100m da queste (e in città è rara una distanza del genere tra le strisce) e siccome il routing che sfrutta i tag sidewalk=left/right/both non fa assolutamente alcuna valutazione del attraversamento direi che IMHO questo sia un difetto ben più grave del eventualità di far allungare la strada (che comunque il pedone può decidere di accorciare attraversando dove ritiene più opportuno, ma a proprio rischio e pericolo) o di non dire il nome della way Quindi in definitiva no! Se ci sono già le way separate è meglio che le lasci. In questo caso, visto che non ci sono differenze in base a cui adottare uno stile di mappatura rispetto ad un altro, scegli lo stile di mappatura che vuoi in base al tempo che puoi dedicare. Inoltre considera anche che: 1)la mappatura con way separate è più esplicita dal punto di vista visivo rispetto ad un tag (invisibile...anche nel routing dove both/left/right ad ora non influenza assolutamente il calcolo del percorso) e, anche se non mappiamo per il render, secondo me questo è un punto a favore visto che facilita l'identificazione di incongruenze/inesattezze. 2)per quanto concerne il fatto che i marciapiedi così mappati, se non hanno assegnato il nome, diano problemi con le indicazioni, teoricamente questo è un difetto dei programmi di routing compensabile (ne parlano nel wiki e comunque basterebbe ripetere il tag name al marciapiede o creare una relation tra questo e la strada ) e comunque è solo un problema di nome...le indicazioni svolta a destra, svolta a sinistra, attraversa vengono date ugualmente e per queste sono anche più precise che assegnando semplicemente il tag sidewalk=* alla strada. 3) Questo stile di mappatura ha cominciato a venire adottato di recente ma ha già raggiunto un numero di elementi mappati in questa maniera pari a circa la metà della somma dei tag sidewalk=left/right/both 4) Si sta cominciando a proporre da sempre più tempo l'idea dell'utilizzo del tag area:highway=* che naturalmente prevede che strade e marciapiedi vengano mappate separatamente ognuno con la propria relativa area attorno con tag area:highway= , come si può vedere qui[1] Stile di tagging questo che, nonostante sia estremamente avanzato e lungo(quindi effettuato solo da mappatori esperti che probabilmente usano JOSM o Merkaartor) , è già parecchio utilizzato come puoi notare qui [2] 5) una strada con la mappatura tramite tagging deve venir divisa ogni volta che lungo il suo percorso cambiano delle condizioni (e quindi dei valori dei tag). L'aggiungere la condizione della presenza di un marciapiede aggiunge una o più possibili variabili (dipende da quanto precisamente vuoi descrivere il marciapiede...più la descrizione è precisa + tag si useranno) che potenzialmente potrebbe costringere ulteriori divisioni. Con la mappatura separata teoricamente il marciapiede verrebbe diviso solo la dove cambino i valori del marciapiede e la strada solo la dove cambiano i valori della strada. secondo me più ordinato, più intuitivo e facile da capire anche per i nuovi mappatori in generale su osm qualsiasi cosa mappata correttamente è/potrebbe essere utile. scegli secondo le tue capacità/possibilità. quei marciapiedi separati, se mappati correttamente, quindi sono utili. [1]http://wiki.openstreetmap.org/wiki/Key:area:highway [2]http://taginfo.openstreetmap.org/search?q=area%3Ahighway - Ciao, Aury -- View this message in context: http://gis.19327.n5.nabble.com/Marciapiedi-tp5779379p5779888.html Sent from the Italy General mailing list archive at Nabble.com.
Re: [Talk-it] Alcuni articoli Wikipedia mappabili in OSM
Il giorno 03 ottobre 2013 18:45, Luca Delucchi lucadel...@gmail.com ha scritto: ... ho alcune domande e suggerimenti: - primo potremmo mettere il codice in qualche repository in modo da lavorarci con più facilità? Ho iniziato ad informarmi su git, ma fin'ora non lo ho mai usato... Quando avrò messo lo script su un repository ti avviserò. - io lascerei il nome completo del file pbf uguale a quello di scaricamento oppure avere due variabili diverse (aiuterebbe a non dover copiare il file se già presente con altri per altri programmi) Lo script scarica: http://download.geofabrik.de/europe/italy-latest.osm.pbf lo salva con nome: italy.osm.pbf e lo converte in: italy.o5m Vorresti che restasse italy-latest.osm.pbf e poi convertito in italy-latest.o5m? - avere un install che controlla le varie dipendenze e le installa se mancano (posso farlo io) Se vuoi farlo tu ti ringrazio, io non saprei come fare. comunque ho fatto il download ma poi mi è uscito questo errore ... sembra che non entri nella funzione convert_pbf_to_o5m Forse perché c'è un return subito sotto l'inizio della funzione (non so come ci sia finito...): riga 293 di launch_script.py. Eliminalo e riprova, per favore. Ciao, Simone ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
