Re: [OSM-talk] Affordable 1 CM high precision GPS.
Hi, On Tue, May 07, 2024 at 12:34:51PM +0200, Hartmut Holzgraefe wrote: > On 5/5/24 21:40, Greg Troxel wrote: > > but it (15cm georeferenced aerial images) does not work in tree cover > > not having watched the video either, and having just a very basic > understanding of RTK, but wouldn't that basically be affected by reflections > from trees the same way as regular GPS, and so be less precise when being in > a forest? At least in Germany we have a grid of Basestations which offer their RTCM 3.1/3.2 Data via NTRIP which is called SAPOS. As there are huge differences between different states at least in some of them its for Free. https://sapos.de/ https://zentrale-stelle-sapos.de/produktinformation-2024-01/ Comparing to Northrhine-Westfalia https://www.bezreg-koeln.nrw.de/system/files/media/document/file/geobasis_rb_sapos_nutzerinfo_varianten_eps_heps.pdf Where it says that the NTRIP caster for NRW is free of charge for real-time applications. So - there are possibilities to use that with an RTK enabled Chipset without having your own base station. Flo -- Florian Lohoff f...@zz.de Any sufficiently advanced technology is indistinguishable from magic. signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] recommendation for JSON to CSV converter
On Fri, Mar 01, 2024 at 03:23:29PM +0100, Martin Trautmann wrote: > On 01.03.24 14:52, Florian Lohoff wrote: > > > For obvious reasons Essen cant have 2.5 or even 4.4 Mio addresses. > > Yeah, I had noticed by now that this is Essen only. I don't find any > json info for all of NRW, from this year. NRW has not updated their Open Data as they are in the middle of a Data Format switch. I asked them twice already They havent updated "Hausumringe" aswell. Flo -- Florian Lohoff f...@zz.de Any sufficiently advanced technology is indistinguishable from magic. signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] recommendation for JSON to CSV converter
On Thu, Feb 29, 2024 at 10:17:28PM +0100, Martin Trautmann wrote: > On 28.02.24 22:58, Florian Lohoff wrote: > > > For these kind of simple conversions there is no need for programming. > > > > Its a GeoJSON Featurecollection. So a list of GeoJSON features, > > each of them having a "properties" objects with all the attributes > > > > jq -r ".features[] | > > [.properties.Strassenna,.properties.HsNr_Zus,.properties.Xg,.properties.Yg] > > | @csv" Hauskoordinaten_0822.geojson > > "Stinnesstr.","8",7.010088,51.525567 > > "Timpestr.","29",7.010417,51.522377 > > "Hattramstr.","31",7.003345,51.52098 > > "Spakenbroich","69",7.003248,51.523044 > > "Bertramstr.","36",7.005647,51.522393 > > "Bertramstr.","38",7.005608,51.522429 > > "Bertramstr.","40",7.005566,51.522469 > > [...] > > Thanks, that worked pretty well. So I'll have a closer Look at jq now. > > I'll have to figure out why the geojson contains 99 606 records only, > although the former version contains 4 418 144 records Most likely lines, not records. A JSON objects spans a lot of rows so counting rows is the issue. 2.5 Mio lines, 99606 Features, 1 Featurecollection. flo@p5:~$ wc -l Hauskoordinaten_0822.geojson 2589766 Hauskoordinaten_0822.geojson flo@p5:~$ rgrep Feature Hauskoordinaten_0822.geojson | wc -l 99607 For obvious reasons Essen cant have 2.5 or even 4.4 Mio addresses. Flo -- Florian Lohoff f...@zz.de Any sufficiently advanced technology is indistinguishable from magic. signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] recommendation for JSON to CSV converter
Hola, On Wed, Feb 28, 2024 at 04:16:24PM +0100, Martin Trautmann via talk wrote: > Is there any JSON converter that you would recommend? > > There are plenty of web services, but none of those worked for me, on > <https://opendata.essen.de/sites/default/files/Hauskoordinaten_0822.geojson> > (70 MB) > > There are plenty of starter tutorials, in order to use python, > javascript etc. > > But those did not work either. > > I tried dasel, without success (dasel version v2.5.0) > > So I wonder what the best solution might be, apart of writing my own > converter (probably in perl). > > What I would expect is hopefully a 100 % conversion - or an error log > which data could not be processed. > > The problem here seems to be the nesting of several levels. For these kind of simple conversions there is no need for programming. Its a GeoJSON Featurecollection. So a list of GeoJSON features, each of them having a "properties" objects with all the attributes jq -r ".features[] | [.properties.Strassenna,.properties.HsNr_Zus,.properties.Xg,.properties.Yg] | @csv" Hauskoordinaten_0822.geojson "Stinnesstr.","8",7.010088,51.525567 "Timpestr.","29",7.010417,51.522377 "Hattramstr.","31",7.003345,51.52098 "Spakenbroich","69",7.003248,51.523044 "Bertramstr.","36",7.005647,51.522393 "Bertramstr.","38",7.005608,51.522429 "Bertramstr.","40",7.005566,51.522469 [...] Flo -- Florian Lohoff f...@zz.de Any sufficiently advanced technology is indistinguishable from magic. signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] JOSM plugin to increment or decrement house numbers
On Thu, Dec 29, 2022 at 12:47:48PM +, Andy Mabbett wrote: > A local street has houses numbered even on one side, odd on the other. > > One number has been missed from the middle of the even side, so every > number from that point to the end of the road needs to be increased by > 2. > > Is there a JOSM plugin that will do this? I thought the Address Preset/Annotate Address already has this. There is a "-2,-1,+1,+2,X" next to the housenumber. Flo -- Florian Lohoff f...@zz.de Any sufficiently advanced technology is indistinguishable from magic. signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] QA tool for finding nameless highways that are armchair-fixable
On Sun, Nov 27, 2022 at 09:16:14PM +0100, Lukas Toggenburger via talk wrote: > Hi all > > As you might know, OSM data contains a lot of highway=* without > name=*. Check your region using the following query: > IMHO a highway=service, track etc typically do not have names. Hopefully you account for that. And i am not shure the assumption that other road classes always have names holds up. Higher class roads may have ref= but not name=* IMHO any assumption about name= (On any object) is pretty difficult and not worth the hassle. Flo -- Florian Lohoff f...@zz.de Any sufficiently advanced technology is indistinguishable from magic. signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Starrflügel-Drohne für Luftbilder
On Fri, Aug 14, 2020 at 06:35:44PM +0200, Florian Lohoff wrote: > Ich hab mich grob an dem hier Orientiert - Der hat eine komplette > Teileliste: > > https://blog.seidel-philipp.de/fpv-wing-aus-kopter-teilen-bauen-mit-inav/#Empfohlene_Teileliste > > Der hat da alles was du brauchst als Erklärung. Ach ja - Das ganze First Person View (FPV) zeugs hab ich natürlich weggelassen. Das hat mich nicht interessiert. Insgesamt ist der Styroporflieger leider ein ganz kleines bisschen zu klein für den Kameraeinbau. Man sägt doch ordentlich dran rum. Ich habe auch Steuerung und co alles nach vorne in die FPV Bay verlegt damit ich zentral platz für den Akku und die Kamera habe. Akku ist mit Abstand das schwerste und muss möglichst nah an den Schwerpung/Neutralpunkt. Also statt 80cm Spannweite hätte ich lieber 1m und ne größere Bay innen. Aber gut. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Starrflügel-Drohne für Luftbilder
Hi Frederik, On Fri, Aug 14, 2020 at 11:59:15AM +0200, Frederik Ramm wrote: > Hallo, > > kennt sich jemand aus beim Stand der Technik mit Starrflügel-Drohnen? > Ich hätte gern so eine, die man in die Luft schmeisst und die dann ein > paar Bahnen über dem Baugebiet dreht und ein schönes Luftbild macht. Und > möglichst keine 20.000 Euro kostet ;) > > Wenn ich die Rechtslage richtig verstehe, ist es ja nicht verboten, dass > die Drohne selber (nach einer vorporogrammierten Bahn) fliegt - ich muss > sie lediglich immer im Blick haben und die Steuerung übernehmen können, > falls was wäre, oder? Ja - ich habe das gebaut mit zeugs von Hobbyking und Co. Rechtslage mal aussen vor gelassen - Ja - Die fliegt autonom und man kann das einfach planen - Mit ein bisschen Übung kriegt man die in die Luft geworfen ohne das was zu Bruch geht. (Am Anfang macht man einfach mal ein paar Propeller kaputt weil man den Boden küsst) aber das ist quasi Verbrauchsmaterial. Am Ende hat die ne schöne Steuerung (Alles Open Source) die automatisch Startet wenn man sie in die Luft wirft (Also gerade leveled und leicht steigt mit Vollgas) bis man die Steuerung übernimmt - Dann kann man manuell fliegen oder eben über einen Switch die vorprogrammierte Flugbahn aktivieren. Dann steigt der auf die Sollhöhe und fliegt dann eben ein Muster ab. Hier war das eher so nen bisschen schwierig weil das dingen ECHT Strecke macht. D.h. einfach nur ein paar linien sind ggfs schwierig weil der natürlich am ende Wenden muss und das braucht raum d.h. auf 20m wendet der nicht. Bedarf auch ein bisschen Übung das zu planen. Man sieht dann hinterher im GPS Track schön wie sehr der auf der Planung geblieben ist. Das Dingen liegt schön ruhig in der Luft und die Bilder sind entsprechend gut. Man kann das dann zusammenstitchen mit dem OpenDroneMap zeugs und man bekommt Bilder. Ich habe den Akku noch nie leer genudelt und Airtime ist 60 Minuten und länger wobei ich nach 20 Minuten immer mit allem Fertig war. Die hat ein "Return to Home" was sehr schick ist. Wenn man sich nicht mehr sicher ist wie die Fluglage gerade ist - Switch umlegen und die kommt zurück und fängt über dir das kreisen an. Ich habe das mal in Neubaugebieten gemacht wo nur die Planstraßen bisher da waren so das ich die schonmal habe. Leider ist nach dem Zusammenstitchen mit dem OpenDroneMap zeugs die Lagegenauigkeit nicht zu vergleichen mit dem was z.b. bei den Deutschen ESRI Bildern man so kennt/erwartet. Vielleicht bin ich da auch einfach nicht so weit oder hab Dinge nicht verstanden. Teilweise hat man eben auch Warp. D.h. die Kanten sind gut aber in der Mitte ist es gestaucht und gestreckt. Aber gut - Um eine Straße und ggfs ein paar Bäume/Rohbauten reinzunageln damit man überhaupt was hat geht das gut. Kosten waren glaube ich <500€ und nen paar Tage basteln. Kamera hab ich mir die kleine Powershot meiner Tochter geklaut und dann die CHDK Firmware drauf gemacht damit die einfach jede Sekunde ein Bild macht. Ich hab mich grob an dem hier Orientiert - Der hat eine komplette Teileliste: https://blog.seidel-philipp.de/fpv-wing-aus-kopter-teilen-bauen-mit-inav/#Empfohlene_Teileliste Der hat da alles was du brauchst als Erklärung. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSRM-talk] Comparing routes from different datasets
Hi Martin, On Tue, Jul 14, 2020 at 05:07:04PM +0200, Martin Schmidl wrote: > Hi, > > In a project of mine I am using OSM data from a city for 7 different years. > Recent data from 2020 acts as the reference. I want to see how different > changes in the data will affect the routing for quality reasons (e.g: If i > used data from 2014 today, will my route be better or worse?). > > For this I am using OSRM on the 2020 data to get a reference route. I > planned to check if the same route is possible in the older datasets from > 2014 to 2019 (if the same route isn't possible, I am computing the route to > the destination). I already tried to use some of the values from the > reference route, however many values (like node IDs or locations) change > over the different datasets and i can't really compare them to the original > reference route. Maybe someone has already done something similar and can > tell me what parameters were used from the routing result, i would really > appreciate that. I am doing route QA since 2013 on an hourly basis for a small part of Germany. So i check whether predefined nodes (~1000) are still reachable and if route distance and time have changed. If it changes from dataset now() to now()-1 Hour i get an email noting the routes which have changed. I grouped the nodes into "clusters" which is more or less one community/town/city so my any-2-any matrix does not get too large. Still its about 60K routes every hour. I have all routes or better the full OSRM result in a database and the full geometry. By this i try to find mapping errors of motorways, junctions etc on the high priority street network. Mails contain a link which overlays both routes to a map e.g.: https://osm.zz.de/routeqa/?rid=243864,251488#52.02004,8.53483,15z Green is current and red is historic route. This was caused by a change at "Jahnplatz" which is now closed for 2 years for construction. If you click on the routes it shows distance and time. This change caused about 400 routes to change because its an important junction. Most of the work is finding and maintaining the nodes. The cost/distance of the network changes all the time so you have small changes here and there. Sometimes you have nodes which have multiple paths which are exactly the same time (Its fastest route - not shortest) so you have flapping routes which you can only eliminate be disabling nodes in your network. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
Re: [Talk-de] Tagging historischer, aber nicht amtlicher Straßennamen?
On Sun, Jul 12, 2020 at 07:29:23PM +, Elstermann, Mike wrote: > Hallo zusammen, > > wie kennzeichnet man eine Straße richtig, die es früher gab, die heute noch > als Bauwerk vorhanden, aber nicht im aktuellen amtlichen Straßenverzeichnis > geführt wird? > > https://www.openstreetmap.org/way/11609716#map=18/51.49553/11.97901=D Es gäbe ja sowas wie old_name. https://wiki.openstreetmap.org/wiki/Key:old_name Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Facebook acquires crowdsourced mapping company Mapillary
On Fri, Jun 26, 2020 at 01:23:05PM +0200, Marc M. wrote: > Hello, > with this in mind 20k€/year for storage is one to explore. > distributed storage, too. > > I don't care about SLA. Does OSM have SLA? > No, we're doing the best we can. The point is when you distribute your storage to people at home we will have at most 10% of images online all the time. So the user experience clicking on images will be awful so nobody will use it. Disregarding the case that upstream bandwidth internationally is pretty bad so you tend to have access times for images of about 4-5 seconds at best. (3MByte image at a typical ADSL upstream with 1.5MBit/s and international latencys) Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Facebook acquires crowdsourced mapping company Mapillary
On Thu, Jun 25, 2020 at 05:25:28PM +0200, Marc M. wrote: > Le 25.06.20 à 16:16, Florian Lohoff a écrit : > > Mapillary themselves say on their web pages that they already > > have 1,199,363,907 images. Thats 3515625 GB or 3.5TB Data > > assuming 3MByte per image. > > 3 500 000 GB ~ 3 500 TB ~ 3.5 PB ? > ~100k€ ~100k$ hardware cost for the storage. > or 1000 people sharing a 6TB disk on a distributed system The 100K$ are recurring costs every 5? years. And you honestly suggest a distributed system? What is the availability for the images - Did you say SLA? I am doing IT Infrastructure for 25 years now and this is NOT a trivial task and it is definitly not a hobby pet project someone is running from his/her basement. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Facebook acquires crowdsourced mapping company Mapillary
Hola, On Sat, Jun 20, 2020 at 12:46:16PM -0700, Mark Wagner wrote: > Serious funding? Yes. Outrageous funding? No. > > Rough estimate: > > * The CIA World Factbook says there are about 64 000 000 km of roads in > the world. > * Google Street View takes 100 photos per km. > * A photosphere from my tablet, compressed using WebP at 50% quality > takes 2.7 MB. Thats pretty much pointless. Have a look at Photos taken which have shown up in Mapillary. There is a history and multiple angles and much more Photos per km than Google Street View. And its not just roads but footways, passages, rivers etc. > This is about 17 280 TB of storage to cover the entire world at Google > Street View quality. It would cost $215 000 per month to store in > Amazon S3, or $89 000 per month in Backblaze B2. It's well within the > capacity of someone like the Wikimedia Foundation. Mapillary says i have 1080km with 164k images thats an image every 6.5m on average. And image is roughly 3MByte for me on average which is NOT a 360° but a 120° field of view. flo@p4:/scratch/local/mapillary$ find . -type f -name "*.JPG" | wc -l 102748 flo@p4:/scratch/local/mapillary$ du -sk . 315372436 . flo@p4:/scratch/local/mapillary$ echo $[ 315372436 / 102748 ] 3069 So i produce 500GB per 1000km of ways - not just roads. Assuming that the amount of ways is twice the number of roads and we have 4 points in time we take a Photo thats 64 000 000km * 2 * 4 thats 512 000 000km of road times the 500GB per 1000km thats 256 000TB so the amount of money is at least an order larger. Mapillary themselves say on their web pages that they already have 1,199,363,907 images. Thats 3515625 GB or 3.5TB Data assuming 3MByte per image. So yes - You need serious funding. And i dont say that thats out of reach of Wikimedia but its not a simple home project. And we didnt talk about transfer costs etc. If you do some Machine Learning and post processing you touch every image multiple times. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] "Driveway" als Fläche üblich/erlaubt?
Hi Volker, On Thu, Jun 25, 2020 at 01:05:55PM +0200, Volker Schmidt wrote: > Ohne Kenntnis vor Ort (Manuel, kannst du eine Beispiel verlinken, am besten > mit Foto) würde ich sagen: > Driveways, zumindest solche die für Anlieferverkehr benutzt werden, sollten > als routable highway in den Daten stehen. > Für das Rendering ist im beschriebenen Fall eine Fläche nützlich, daher > würde ich area:highway=* für geeignete halten. > > @Florian: Ich verstehe das "nur" in deiner Bemerkung "Jegliches > Flächenmapping ist nur für den Renderer" nicht. Natürlich sind OSM Daten so > zu strukturieren, das ein Renderer sie "verdauen" kann, und daraus > Landkarten herstellen kann (steckt sogar im Namen des Projekts: OpenStreet > *Map*). Aber wir erfassen Fakten und das machen wir nicht ausschliesslich um eine "Schönen visuellen Eindruck" zu bekommen. Das sind z.b. die ganzen Vorgärten die als landuse=grass eingetragen werden was einfach nur eine Vergewaltigung der landuse tags ist. Und ja - wir wollen Straßen irgendwann als Flächen erfassen aber für das routing bringt das nichts. Das ist eben nur damit es schöner aussieht was MIR relativ egal ist. Und wenn jemand das einträgt ist das eben NUR für das schicke aussehen. Die Aussage zwischendurch "... IMO nur da verwendet werden, wo eine Bewegungsrichtung nicht sinnvoll ist." suggeriert das ein Flächenmapping irgendwas mit Bewegungsrichtungen zu tun hat ist halt falsch. Die Fläche ist eben nur schick zum ansehen und hat mit Bewegung im Routing/Navigation nichts zu tun. Und Fläche ersetzt nicht den eigentlichen Weg sondern ergänzt den nur. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] "Driveway" als Fläche üblich/erlaubt?
Hi, On Wed, Jun 24, 2020 at 10:10:10PM +0200, Hubert87 wrote: > Dem würde ich widersprechen. > hw=* + area=yes sollte IMO nur da verwendet werden, wo eine > Bewegungsrichtung nicht sinnvoll ist. z.B. Marktplätze. Dann aber ohne > zusätzlichem hw=* (vom gleichen Typ) "quer" über diese Fläche. Quer über die Fläche geht mit aktueller Technik sowieso nirgends. Jegliches Flächenmapping ist nur für den Renderer. > @Manuel: Bitte schau mal nach, ob ggf area:highway etwas für Dich ist. > Wird aber noch nicht auf osm.org gerendert, aber das steht sowieso auf > einer anderen Seite. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] "Driveway" als Fläche üblich/erlaubt?
On Tue, Jun 23, 2020 at 07:18:37PM +0200, Manuel Reimer wrote: > Hallo, > > bei uns gibt es in der Nähe mehrere Ansammlungen von Garagen. Die Zufahrten > dazu habe ich alle mit "highway=service" und "service=driveway" eingetragen. > Allerdings entspricht das eigentlich nicht den örtlichen Gegebenheiten. > Für's Routing wäre es nicht falsch (sofern es wirklich jemand nötig hat sich > bis in seine Garage routen zu lassen) aber eigentlich ist die ganze Fläche > vor und zwischen den Garagen-Reihen gepflastert. Man könnte einen beliebigen > Weg über dieses Pflaster zur Garage nehmen. > > Wäre es nun richtig, bzw. sinnvoll die Fläche *zusätzlich* zu den Wegen mit > "area=yes" und den gleichen Tags wie für die Wege zu versehen um > darzustellen das die ganze Fläche "driveway" ist? Falsch ist das nicht. Für das Routing ändert das nichts. Sieht vielleicht nur "hübscher" in der Karte aus. Ich mache sowas nicht weil ich immer denke "je mehr Objekte des komplizierter das zu maintainen". Also trage ich Zeugs ein was FÜR MICH Sinn ergibt. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Facebook acquires crowdsourced mapping company Mapillary
Hi Nick, On Fri, Jun 19, 2020 at 11:47:01AM +, Nick Whitelegg wrote: > > (Disclaimer: I am the developer of said project) > > You can login using your OSM account. The issue is that once you start pushing stuff into any projects your storage expenses will kill you pretty fast. https://www.backblaze.com/b2/cloud-storage-pricing.html Thats 0.005$ per GB and Month. Thats *12 *1024 for a Terrabyte. Thats something like 60$ per Year per Terrabyte which sounds reasonable concerning disk costs. Costs per disk per lifetime and infrastructure to connect it to the IP Network. Since late May i have produced: flo@p4:/scratch/local/mapillary$ du -sh . 285G. flo@p4:/scratch/local/mapillary$ find . -type f -iname "*.jpg" | wc -l 97407 So just pushing worth like 2 Weeks of taking street imagery will cost the Hoster about 20$ per year from now on. And i have pushed multiple terrabytes to Mapillary since 2014. And thats just me. Put that to a global OSM perspective and you need serious funding for storing all that imagery, let alone the CPU cycles for your compute vision to blur faces and number plates. And as i have done something like OpenStreetcam 10 years ago for my personal imagery without the fancy blurring stuff. And i have worked for Hosting companys so i know the deal. This is why I think personally that the Facebook deal is the only viable option for getting long term funding for storage. Somebody has to pay for it. And i dont see a real businesscase which will pay up for all the random Dashboards people store into your Dataset. So either Facebook supports this service or we are toast. The only option would then be OSMF funding but you may have a glimpse at the Mapillary numbers and prepare some fundraising. Flo -- Florian Lohoff f...@zz.de UTF-8 Test The ran after a , but the ran away signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Facebook acquires crowdsourced mapping company Mapillary
Hola, On Fri, Jun 19, 2020 at 03:17:31PM +0200, Mateusz Konieczny via talk wrote: > > Openstreetcam is pretty much "disfunct" from my perspective. There are > > tons of bugs people opened because of their tracks not beeing > > processing. Same for me. Twitter feed dead for a year. It looks pretty > > much abandoned since end of 2019 - Since early June serious problems > > processing tracks and uploads. > > > Can you link some of this bugs? > > I found https://github.com/openstreetcam but I see nothing about blocked > processing. > > https://wiki.openstreetmap.org/wiki/OpenStreetCam is not describing is as > dying, what > should be changed if it is becoming defunct - I have uploads hanging in processing since end of May, also some uploads which are finished are still showing upload. - Since early June there is no reverse geocoding - No page lists contact informations - Twitter account dead for 12+ Month - Pretty much "nothing" happening in the git repos since end of last year So bugs, operational down or broken and noone to really talk to. After i opened a bug put in my tracks not beeing processed there were voices says that never anything comes back into the bug reports but some bugs disappear magically. Comparing that to other projects i am contributing this is dysfunctional. I dont know what happened behind the scenes but it feels as when Telenav lost interest and grab "took over" with pretty much nothin in their hands. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Fwd: [OSM-talk] Facebook kauft Crowdsourced Mapping Firma Mapillary
On Fri, Jun 19, 2020 at 09:19:46AM +0200, Martin Koppenhoefer wrote: > > > sent from a phone > > > On 19. Jun 2020, at 09:09, Florian Lohoff wrote: > > > > Ja das ist > > eine Datenkrake aber bisher ist doch nichts passiert!?! > bei Facebook ist schon einiges passiert. Klar, kann einem evtl. egal sein, > aber zu sagen bisher ist überhaupt nichts passiert, trifft es eher nicht für > mich. Bei Facebook schon aber nicht bei Mapillary. Da werden gerade Pferde scheu gemacht obwohl noch nichts passiert ist. Vorsorgliche schonmal alles löschen. > > Also warum die > > aufregung. Wenn die dann die mapillary app einstellen und an eine > > facebook id koppeln dann können wir immer noch maulen. > > dann wird es auch dem letzten klar werden, aber “machen” kann man dann > nichts mehr. Noch kann man sich die eigenen Bilder kopieren (falls man > sie nicht sowieso auch lokal in Kopie gehalten hat) und hoffen dass > jemand irgendwann einen alternativen Dienst anbieten wird, wo man sie > hochladen kann. Machen kannst du auch heute an der nummer schon nichts mehr. Wir sind und waren eh immer nur Beifahrer. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fwd: [OSM-talk] Facebook kauft Crowdsourced Mapping Firma Mapillary
On Fri, Jun 19, 2020 at 08:52:55AM +0200, Hessler, Klaus-Michael wrote: > Danke Michael und Markus, > > > Weitergeleitete Nachricht > > > Betreff: [OSM-talk] Facebook acquires crowdsourced mapping > > > company Mapillary > > > Datum: Thu, 18 Jun 2020 22:32:42 + > ich war kurz davor, mich dort anzumelden und die Funktionen zu nutzen. > > Ist die OSMF oder sonstwer dabei, eine Alternative zu schaffen? > Was ist mit OpenStreetCam > <https://wiki.openstreetmap.org/wiki/OpenStreetCam>(DE > <https://wiki.openstreetmap.org/wiki/DE:OpenStreetCam>), gefunden über > AlternativeTo.net <https://alternativeto.net/software/openstreetview/>? Was > kann OpenStreetCam nicht, gibt es bessere Alernmativen? OpenStreetCam kann keine Wege die nicht von Autos befahren werden. Sprich. OSC mapped Bilder auf die Wege in OSM - Sind die Wege nicht dar oder nach deren Meinung nicht befahrbar siehst du die Bilder nicht auf der Karte (Sie sind aber da). Hat den Nachteil das du nur Fotografieren kannst was schon da ist, und halt auch nur Auto zentrierte Infrastruktur. Mapillary ist um längen zuverlässiger und passt deutlich besser zu OSM. Ich sehe die Übergang zu Facebook nicht als so gravierend. Ja das ist eine Datenkrake aber bisher ist doch nichts passiert!?!? Also warum die aufregung. Wenn die dann die mapillary app einstellen und an eine facebook id koppeln dann können wir immer noch maulen. Ich sehe da gerade einen Vorteil denn ich habe mich immer gefragt wie Mapillary den Storage bezahlt. Ich alleine hab da vermutlich ein Terrabyte an Bildern reingeschoben. Und das ja nur für einen ganz kleinen teil der Welt. Die Kosten müssen explodiert sein was die "lagerung" der Daten angeht. Hier kann halt Facebook aushelfen. Für die sind die Datenmengen peanuts. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Facebook acquires crowdsourced mapping company Mapillary
On Fri, Jun 19, 2020 at 01:21:59AM +0200, Niels Elgaard Larsen wrote: > Paul Johnson: > > Great. How's this affect those of us who trust Facebook about as far as we > > can throw it? > > > Use openstreetcam Openstreetcam is pretty much "disfunct" from my perspective. There are tons of bugs people opened because of their tracks not beeing processing. Same for me. Twitter feed dead for a year. It looks pretty much abandoned since end of 2019 - Since early June serious problems processing tracks and uploads. And for the me focus on Car driveable streets makes it useless. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
On Fri, Jun 12, 2020 at 11:19:46AM -0400, James wrote: > No they shouldn't, mapping roads in northern Canada, your bbox can become > quite large quickly as mapping logging roads/dirt roads is quick and easy, > but span over multiple kms The point is that the line/way of that road should also not span tens of kms. You should break that up every couple of kilometers. Otherwise this is prone to break one day or the other. And its simply inefficient. Every time you touch that road you invalidate hundrets of tiles. When i load some area in josm and there is an object which spans multiple times of my edit area i typically split it down. Be it roads or waterways. And there are few tags which REALLY span that long objects. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
On Fri, Jun 12, 2020 at 03:45:17PM +0200, Frederik Ramm wrote: > Hi, > > On 12.06.20 15:22, Dave F via talk wrote: > > There is a lot of negativity about large changsets, but assessment of > > them should be based on quality, not quantity. > > Yes, we're not discussing a popup that says "You dumbass, why did you > create a world-spanning changeset?" ;) > > The way in which editors deal with that would likely differ; in JOSM it > might be a popup that says "are you sure?" and in ID it might be a > floating warning somewhere. I'd rather let josm not download additional data in some distant spot as long as you have unpushed changes. Same could be with id - dont let user pan/zoom aways to distant spots without first pushing their changes. By this you actually force the use to split their changes spatially. It will still let you edit big objects as you loaded them in the first place. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
On Fri, Jun 12, 2020 at 02:14:15PM +0200, Mateusz Konieczny via talk wrote: > > > > Jun 12, 2020, 13:59 by f...@zz.de: > > > Changeset envelopes which span more than 100s of km² are broken. > > > Except cases where you edit/delete already created huge objects or you create > huge object that actually should be created. > These types of objects should be pretty exceptional. I try to split landuses to sub 1km² because i also feel the pain for rendering tiles. As soon as someone touches those areas you invalidate tons of tiles. So breaking this down also benefits us long term concerning workload on the tile servers. Main reason is still maintainability though. As soon as an object is not in the Mappers complete view things tend to break. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
On Fri, Jun 12, 2020 at 01:00:56PM +0200, Frederik Ramm wrote: > Hi, > > I wonder if it would be feasible or desirable for editors to warn users > if they are at risk of creating country/world-spanning changesets. > Something like "you have unsaved edits more than 500km away from where > you are editing at the moment, please upload those before you continue" > or so. > > World-spanning changesets are a constant source of irritation, and very > rarely intentional. Yes please - I am using Osmcha to look at changesets around me and i have a high number of changesets which span half Europe and thus intersect with the area i am looking at. Changeset envelopes which span more than 100s of km² are broken. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Massenweise Entfernung von oneway=no
On Wed, Jun 03, 2020 at 11:06:58AM +0200, pbnoxious via Talk-de wrote: > Hallo, > > ich finde gerade die Diskussion oder den Wiki-Eintrag nicht mehr, aber > in meiner Erinnerung war für "sidewalk" und "lit" die Regel, dass > Straßen innerorts (also v.A. highway=residental, aber auch größere > Straßen) normalerweise sowohl beidseitige Gehwege haben als auch > beleuchtet sind, während es außerorts genau anders herum ist. Besonders > Abweichungen von der Beleuchtung (also z.B. unbeleuchtete Straßen > innerorts) sind ja in Deutschland wirklich eher die Ausnahme als die Regel. Sowas würde und kann sich nicht durchsetzen weil wir dann erstmal alle Straßen taggen müssten die Inner oder Ausserorts sind. Da wir das nicht machen folgt dem das wir alles wohl explizit setzen müssen. Und bei den tags wie sidewalk, shoulder, cycleway, lit, surface mache ich das - Bei oneway nicht. Und da stellt Volker natürlich zurecht die Frage warum. Und das einzige was mir als Unterscheidungskriterium einfällt ist die Statistische Verteilung der tag values Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massenweise Entfernung von oneway=no
Hola, On Tue, May 26, 2020 at 12:04:11PM +0200, Protoxenus via Talk-de wrote: > Flo schrieb: > > > > > > Wenn kein Fußweg/Radweg da ist, wird auch keiner getaggt, das ist das "NO". Keiner getagged heist kein tag - nicht sidewalk=no > > Wenn du das damit aufweichst, öffnest du damit wieder die Büchse der Pandora. Ich weiche nichts auf - Das ist wie es heute läuft. Wenn etwas nicht da ist wird es nicht getagged. Siehe Beispiel oneway=no. Die frage ist eben wie wir "Zustand unbekannt" und "Nicht getagged d.h. nicht existent" unterscheiden. Und da gibt es kein Patenrezept für. Wenn ich Gebiete nach Mapillary Bildern überarbeite dann kriegen alle Wege ein lit=yes/no shoulder=no/left/right/both sidewalk=no/left/right/both cycleway=no/left/right/both surface= lanes= maxspeed= (Ausser living_street) source:maxspeed= ggfs dann noch: priority_road=designated hazmat=designated > Einmal das > > "NO", es ist nicht erlaubt: -> du darfst hier nicht lang > und > "NO" es ist nicht da: -> keine Beleuchtung Nein - Der unterschied - "Wir wissen es nicht" und "Keine beleuchtung" Die Absenz des "lit=no" kann heissen - "Hat sich keiner drum gekümmert" oder eben "Es gibt keine Beleuchtung" Deshalb ist das explizite taggen eben dann die Aussage - "Ja - Ich habe hingesehen - Nein - es ist nicht beleuchtet". Aber wie weit treiben wir das. Auch in tags die eine Verteilung von 99.999% zu 0.001% haben? Dann haben wir demnächst noch überall ein tunnel=no covered=no auf allen wegen. Also bei welchen tags machen wir das und bei welchen nicht? Und wie unterscheiden wir - "Hab ich mir angesehen - ist nich da" und "Hab sich niemand angesehen" > Wir haben einen "Grundzustand", der ist = "nichts", alles Andere wird > hinzugefügt. Falsch - Implizit sind auf allen wegen access tags. Siehe auch die wiki Seite zum Thema routing access tags und es ist eben ein oneway=no angenommen. D.h. es gibt ganz viele implizites wissen das wir erstmal annehmen aber nicht taggen. > Als ich bei OSM angefangen habe, galt die Regel: Was nicht da ist, > wird auch nicht getaggt. Leder wird das immer mehr aufgeweicht. So - Straßenbegleitender Radweg - Linksseitig nutzbar und ggfs sogar angeordnet - Taggst du den mit oneway=no? Taggst du alle anderen die nur rechtsseitig Nutzbar sind mit oneway=yes? Ich finde hier das taggen von oneway=no bei angeordnetem linksseitigem Radweg für extrem hilfreich weil es eben genau diese information beinhaltet. Macht das Sinn das auf allen Wegen zu machen die keine Einbahnstraße sind? Und wenn wir tags haben mit einer Verteilung von 50:50 dann macht das taggen beider Zustände richtig viel Sinn, dann wird klar - haben wir uns angesehen. Ab welcher Verteilung macht das keinen Sinn mehr weil der "yes" fall so selten ist das das taggen von "no" Unsinn wird. Absolute ausnahmen wie covered oder tunnel machen sicherlich keinen Sinn. Shoulder? Lit? Oneway? Sidewalk? Cycleway? Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] openstreetcam tot?
Hola, On Mon, Jun 01, 2020 at 07:00:52PM +0200, Martin Scholtes wrote: > Hallo Flo, > > hättest besser die Mail heute morgen schreiben sollen. Mano. Naja - ich war den ganzen Tag unterwegs neue Bilder machen. Und hab eben gesehen das der immer noch nicht fertig war mit den Bildern. > Aber ich habe es auch gemerckt, das der Upload länger als normal dauert, > und gerade jetzt geht gar nichts mehr. Naja die letzten 2 Wochen hat das immer schon die ganze Nacht gedauert da Zeugs reinzuschieben. Im moment produziere ich am Tag ~6-10k Bilder und wenn ich zwischen 60 und 150 Sekunden je Bild brauche sind das halt 12000 Minuten für den Upload wenn es doof läuft. Sind halt 10 Tage für einen Tag Bilder. Ich uploade noch an den Bildern vom 28.5. Hab im moment noch 34000 Bilder hier liegen. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] openstreetcam tot?
Hi, seit ein paar Tagen bin ich wieder intensiv am Bilder aufnehmen und lade die hauptsächlich bei Mapillary hoch. Jetzt hab ich mir gedacht das es ja auch Sinn machen könnte die zu OpenStreetCam hochzuladen. Tja - Upload ist eher so bei 90-150s je Bild. Das war bei Mapillary in 45 Minuten getan ist dauert bei OpenStreetCam jetzt schon 3 Tage. Ich produziere im moment mehr Bilder in 24h als ich sie bei OpenStreetCam hochladen kann. Und das liegt nicht an meiner Bandbreite. Dazu tauchen die Uploads in meiner Seite nicht mehr auf. Uploads von vor 4-5 Tagen sind immer noch im Zustand Processing. Das wirkt irgendwie nicht wie ein lebendes Projekt. Dazu scheint der twitter account seit etwa 1nem Jahr ziemlich tot - Antwort hab ich da auch nicht bekommen. Weiss da jemand genaueres? Gibts da eine Mailingliste/Forum oder einen Bugtracker für das operative Projekt? Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Position des FOSSGIS e.V. zu bezahlten Kräften in der OSMF
Hola, On Mon, May 25, 2020 at 10:14:23PM +0200, Michael Reichert wrote: > > Eine gemeinsame Position des FOSSGIS e.V. als Local Chapter der OSMF in > Deutschland zu diesem Thema wird Tagesordnungspunkt auf der nächsten > Vorstandsitzung des FOSSGIS e.V. am Dienstag, den 1. Juni 2020 um 20:00 > Uhr auf dem Mumble-Server podcast.openstreetmap.de sein. > > Welche Meinung habt ihr zu bezahlten Kräften in der OSMF dazu? Stimmt > ihr dem obigen Konsens zu? Oder seid ihr anderer Meinung? Ich habe die original Mail gesehen und hab da nen ganzen Tag so "drauf rum gekaut" und irgendwie fällt es mir schwer eine Tätigkeit zu definieren die nicht dem ein oder anderen auf die Füße tritt. Ich sehe halt den Sysadmin Kram für die OSM Server als eine Baustelle. Das wird irgendwann zu einem Fulltime job den nicht mal irgendwer nebenher macht. Aber wie will man Freiwillige da mit reinziehen. Das ist so ein "ganz oder gar nicht" Nummer. Also Entweder zahlst du dann das ganze Admin Team oder keinen - Aber so einen raus picken der dann Full time dabei ist und noch eine Herde von Zuarbeitern? Ich kann mir nicht vorstellen das so etwas funktioniert. Dann lieber allen einen Halbtagsjob anbieten. Oder sowas wie Nachteinsätze, Bereitschaft oder so zahlen. Aber vielleicht denke ich zu kurz was die OSMF Tätigkeiten angeht. Mit der europäischen Brille ist ja die OSMF eine technische Erfüllungsgehilfin. Das wird in den USA ja anders wahrgenommen. Da ist das ja eher ein "Political body" und da geht es dann vermutlich viel mehr um Community, Lobbying und Co. Und ja - ich fände es auch gut wenn es einen breiten Konsens geben würde welche Tätigkeiten da bezahlt werden und das es quasi abgestimmte Tätigkeitsbeschreibungen gibt. Daher finde ich den Kompromiss gut. Ich habe ja überhaupt keine Links zu der Wikimedia - Aber die haben ja auch irgendwann angefangen Menschen zu bezahlen und haben da den ein oder anderen Fehler begangen. Vielleicht kann man da draus lernen? Und wenn ich die Liste heute durchgucke dann Frage ich mich was die alle machen?! Gefühlt gibt es da für jedes byte einen Senior FooBar. https://wikimediafoundation.org/role/staff-contractors/ Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massenweise Entfernung von oneway=no
On Mon, May 25, 2020 at 01:08:33AM +0200, Tobias Knerr wrote: > Meiner Meinung nach geht die Idee, Default-Werte explizit zu setzen, zu > Lasten der Übersichtlichkeit. Die logische Konsequenz wären ja > maxweight=none, maxheight=none, bridge=no, tunnel=no, covered=no > access=yes vehicle=yes motor_vehicle=yes etc. an fast jeder Straße. Und > wie mappe ich z.B., dass zwischen zwei Straßen keine Abbiegebeschränkung > besteht – lege ich dann jeweils eine Relation mit restriction=allowed > an? Wie mappe ich, dass an einer Stelle kein Gebäude steht, in einem > Gebäude kein weiterer Laden mehr ist, auf dem Gehsteig kein weiterer > Abfalleimer steht, ...? > > Vielleicht etwas übertrieben, aber worauf ich hinaus will: Die > Abwesenheit von einem Objekt oder Attribut sollte normalerweise nicht > erfasst werden – nur in Ausnahmefällen dort, wo sie überraschend ist > (weil es kürzlich anders war, die Luftbilder veraltet sind, es bei den > Straßen drumherum anders ist, ...) . Wenn in deiner Gegend bestimmte > Arten von Straßen oft "umgedreht" werden, kann das durchaus so ein Fall > sein. Ich überlege gerade was ist mit lit/cycleway/sidewalk/shoulder ? So einfach ist es eben nicht. Es gibt zwar defaults die auch Sinn machen. Es gibt dinge deren "seltenheit" macht es Unsinning eben den umgekehrten fall zu taggen oneway=no als Beispiel. Aber was ist mit lit? Da sind ja sowohl lit=no wit auch lit=yes eine information. Und bei lit ist die Verteilung eher 80/20. Was ist mit sidewalk=no, cycleway=no? hat ja ggfs im Routing eine Auswirkung je nach Straßenklasse. Auf einem residential mit sidewalk=no will ich vielleicht noch laufen. Auf einem primary mit lit=no, sidewalk=no vermutlich eher nicht - vor allem nicht Nachts. Also die Regel das nur weil etwas NICHT existiert wir es nicht taggen ist zu kurz gesprungen. Ich glaube das funktioniert im Moment nur deshalb weil jeder da seinen Menschenverstand benutzt - oder eben auch nicht. Ich denke man müsste für jedes tag einzeln durchgehen ob es Sinn macht yes UND no zu taggen und wenn ja wann. Und für einiges haben wir defaults, für anderes aber eher so nicht - bzw eher undokumentiert und gefühlt. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Examples at https://wiki.openstreetmap.org/wiki/Key:access
Hi Colin, On Mon, May 25, 2020 at 10:54:46AM +0200, Colin Smale wrote: > > You cant tell whether this access=private is okay to break, and the > > other not. > > "private" is not the same as "no". It simply means that the owner has > the right to decide who to admit, and the default is "no access" unless > you have explicit or implicit permission from the owner. For some/all routers it is. At least for my QA stuff i use OSRM with default car profile has private -> no. It on the access restrictions blacklist. Those ways basically drop of the graph. Which is IMHO correct. We/Technology cant decide whether we fall into that category of beeing allowed to traverse that specific part of the road network. So technology has to refrain from using it. > With respect to private driveways, they are simply private. The owner > will tolerate friends and neighbours, postmen, delivery drivers etc > coming to the door - you could say they have implicit permission. A > random person however has no implicit permission and must keep out. No - I see this behaviour more as "permissive" - Because you dont have a blacklist until you find somebody to deny access. On the opposite private is "Everybody is on the blacklist with some exceptions". This is not the way a default driveway works. You implicitly allow anyone visiting you to use it, until somebody shouts at you. > In Germany it sounds like it is the same as it is here in the > Netherlands. If you don't put up a sign saying "keep out" or equivalent, > no actual offence is committed by passing the sign onto your land. > However you, as the land owner, have the sole right to erect such a sign > at your discretion and to make the rules as you see fit. Correct - But thats a legalese of private property. So its a matter of ownership not a per se access restriction. Access restrictions come into the game as soon as there is a visible intention e.g. "Keep out" "No trespassing" or even some physical barrier (Which might be a simple rope) > There is also the category "access=permissive" which is in the middle. > You have no statutory right to access the land, however the owner has > clearly decided to allow the public access (i.e. everybody has implicit > permission). The owner can (in theory at least) rescind that implied > easement at any time or otherwise restrict access. permissive is the opposite of private. permissive -> Anyone until further notice private -> Noone until further notice And driveways are for welcoming people you most certainly dont know in advance. So a driveway by behaviour is not private unless you explicitly want it that way. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Examples at https://wiki.openstreetmap.org/wiki/Key:access
ntent of the owner that the driveway is out of bounds - like a sign, chain, gate, fence etc i am happy with taking this intent into OSM by using e.g. access=private. Without such intent there is no need to put access restrictions in place. Thats my case with "On the ground" and "Not every driveway needs an access=private" - We want to have a visible and clear intent verifyable by others that THIS driveway is not to be trespassed. And THEN Amazon Logistics, DHL, DPD can actually trust our values that we correctly reflect intentions. > > So in case this is very different to Poland i would suggest removing the > > driveway from the access examples alltogether and make it a local > > issue. > > > Is it still needed? I made some edits to try to avoid confusion of > "private road, as in restricted access" and "private road, as in privately > owned" > as privately owned roads may be open and publicly owned may be restricted. I am happy with that. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] oneway = no
Hola Markus, On Mon, May 25, 2020 at 08:53:28AM +0200, Markus wrote: > Hallo Florian, > > >> 3 Zustände: > >> - ja > >> - nein > >> - weiss nicht > >> > >> Letzterer muss noch geprüft werden > >> (die anderen Beiden sollen regelmässig auf Änderung kontrolliert werden) > > > > Also nicht das ich nicht gerne label an Objekte hängen würde die ich > > gerne rechecken würde > > Es geht nicht um eine private ToDo-Liste. > Sondern um öffentliche Qualitätsmerkmale der Daten. Naja - Aber alles mit "weiss nicht" erstmal durchtaggen um das nach und nach abzuarbeiten? Ist für mich eine "Private ToDo Liste" Denn am Ende erhebt ja niemand den Anspruch das OSM vollständig ist, ausser vielleicht der Mapper vor Ort, und das ja auch nur für Teilaspekte. > Angenommen, man will möglichst valide Daten, möglichst zeitnah, > dann kommt man um eine Erfassung der Validität nicht herum. Validität steht ja nochmal auf einem vollständig anderem Blatt. Ob es etwas existiert oder nicht oder ob der Zustand unbekannt ist ist ja Vollständigkeit nicht Validität. Bei Validität müssen wir uns ja auf den Mapper verlassen das der Sorgfältig einträgt. Und das es eine scheinbar große Fraktion gibt die gerne nach Gefühl mapped sieht man ja gerade im Access thread im Forum. > Beispiel: > > Viele schreiben "highway=track" an eine Linie, die sie aus dem Luftbild > oder aus Erinnerung vor Ort gemappt haben (weil sie nicht oder nicht > mehr genau wissen, wie das genau war, aber Lage und Form kennen). > Für den Kenner ist dadurch ersichtlich, dass noch etwas fehlt und > verbessern das wenn sie mal vor Ort sind. > (Anfänger denken, dass "track" etwas Genaues bezeichnet, sie aber nicht > genau wissen was). Naja - So funktioniert OSM - Iterativ verfeinern wir Daten. Ich bin mit dem Zeugs was ich eintrage oft nach 10 Jahren noch nicht zufrieden. Nicht weil es unvollständig ist (Was es immer ist) sondern weil es meinen Ansprüchen nach Eleganz und Simplizität nicht entspricht. Also habe ich einen eigenen TaskManager laufen und gehe alle 2-3 Jahre die ganzen Gemeinden durch für die ich mich interessiere. Dauert dann halt 6 Monate sich nochmal alles anzusehen. Und es gibt immer was zu korrigieren. Nochmal zu durchdenken. Auch wenn sich die Realität nicht geändert hat so hat sich mein Anspruch an "Schöne Daten" geändert. Landuses werden verkleinert, anders geschnitten, Multipolygone aufgelöst. Das hat aber nichts damit zu tun das ich erstmal an alle Wege ein "lit=unknown" hänge und das nach und nach abarbeite. > Bei eindeutigen Merkmalen wie "oneway=yes" ist es klar, da steht ein > Schild. Aber wenn ich mich nur erinnere, dass dort "irgendwo" ein Schild > stand, vielleicht in einer anderen oder abzweigenden Strasse, wie kann > ich das dann angeben, damit es Dritte unterscheiden können von "da ist > (vielleicht) was" oder da ist "sicher nichts"? Ich habe 2014-2015 einen Grossteil der Gemeinden stumpf komplett via Mapillary abgelichtet, und bin gerade in einem rerun. Und ja - Ich habe eine neue Einbahnstraße entdeckt. Wie lange die existiert - keine Ahnung. Warum hat die kein anderer Mapper entdeckt? Keine Ahnung. Hätte mir irgendein tag geholfen. Nein - 2014 hätte ich ein oneway=no dran gehängt. Hätte ich mich heute stumpf daran orientiert wäre das heute noch nicht eingetragen. Also ein zu großer Verlass auf Tags ist auch sehr trügerisch - Womit wir wieder bei der obigen Validität sind. Wenn ich mich drauf verlasse was andere eintrage, und das nicht kritisch hinterfrage, ist die Karte innerhalb weniger Jahre unbrauchbar. Es ändert sich ständig was und in Großteilen Deutschlands sind wir seit Jahren im Maintenance Modus. Wie aber bekommen wir mit DAS sich was ändert. Und da hat keiner eine Antwort drauf. Ich Monitore für Adressen die wöchentlichen opendata exporte meines Kreises und kriege Diffs zugeschickt wenn die neue Adressen zuteilen. Und sowas brauchen wir viel mehr. Ich hätte gerne eine Kopie aller Verkehrsrechtlichen Anordnungen - Dann würde man sofort die Geschwindigkeitsänderungen, Einbahnstraßen und Co mitbekommen. Hab ich bloss noch nicht raus bekommen wie ich die bekomme. > Oder bei (strassen)"name=*" bei eindeutiger Ortsstrasse, deren Name ich > nicht kenne? oder bei der es gar keine Namen gibt? > > Je älter OSM wird, desto problematischer werden Konflikte zwischen > "Bekannt" und "Unbekannt". > > Und ja, wenn man das verbessern will: > - brauchen wir definierte Meta-tags > - wird die DB grösser Aber dafür müssten wir ja definieren welche use-cases wir abbilden wollen. Und Vollständigkeit ist ein ganz schlechter Use-Case weil er die Pflege bzw Änderung im Bestand verschleiert. Und ich bin nach wie vor nicht dafür das in die
Re: [OSM-talk] Examples at https://wiki.openstreetmap.org/wiki/Key:access
On Mon, May 25, 2020 at 12:39:11AM +0200, Colin Smale wrote: > > Legally this is broken. Legally you may not enter the zone when > > your destination is not within that zone and there nothing like a > > distance based penalty within that area. > > > > So yes - there is a problem - But not within tagging. Its something > > routers need to solve. > > Routers cannot work alone, they have to work together with the tagging. > It's not fair to claim it's all their problem. If the tagging does not > represent the nuances required, the router should not be expected to > just guess (at least where the difference is between legal and illegal). Dont get me wrong - If there is information missing to distinguish cases i am happy to find new tags/ways to describe them. For a destination case routers need to take that step. If there is a grid of roads all connect each other and all of them are destination its basically a subgraph which you pay a penalty to enter. Its not a "per distance" penalty which it is currently for the ones i am using/testing regularly. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] oneway = no
On Sun, May 24, 2020 at 09:32:28PM +0200, Markus via Talk-de wrote: > Hi Florian, > > > alle default tags nochmal taggen nur damit einige wenige eine > > Vollständigkeitsstatistik führen können ist auch irgendwie missbrauch > > der osm tags oder sehe nur ich das so? > > Ich habe mal gelernt, dass es da 3 Zustände gibt: > - ja > - nein > - weiss nicht > > und dass Letzterer unbedingt noch geprüft werden muss > (und die anderen Beiden regelmässig auf Änderung kontrolliert werden) Also nicht das ich nicht gerne label an Objekte hängen würde die ich gerne rechecken würde - Hatten wir ja auch schon mit den verschiedenen Proposals was check_date oder survery_date angeht. Da wir ja wissen das Kneipen statistisch nur wenige Monate existieren wäre also ein "wiedervorlage" tag super. Die Frage ist eben nachwievor ob wir diese meta-meta informationen in die OSM Datenbank packen wollen. Ich habe da keine harte Meinung zu aber ICH packe meinen Kram da nicht rein sonst explodiert das was ich mir gerne alles merken würde und dann haben wir hier Streit wegen der ganzen tags ;) Und jedes halbe Jahr ändert sich ja der Fokus was man an Tags komplettieren möchte und dann fängt man wieder an sich mehr meta-meta tags zu erfinden. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[OSM-talk] Access tag abuse examples Was: Examples at https://wiki.openstreetmap.org/wiki/Key:access
cycle=agricultural motorcar=agricultural bicycle=yes foot=yes horse=yes highway=track access=agricultural motorcycle=no motorcar=no hgv=no psv=no bicycle=no foot=yes goods=no horse=unknown highway=service access=destination motor_vehicle=no motorcycle=destination motorcar=destination bicycle=yes foot=yes highway=residential motor_vehicle=agricultural;forestry motorcycle=no motorcar=no bicycle=designated foot=designated highway=track access=destination motorcycle=destination motorcar=destination bicycle=yes foot=yes agricultural=yes highway=path motorcycle=destination motorcar=destination hgv=no psv=no bicycle=designated foot=designated goods=no highway=unclassified access=military vehicle=military motor_vehicle=permissive bicycle=permissive foot=permissive highway=unclassified access=military motor_vehicle=permissive bicycle=permissive foot=permissive horse=permissive highway=unclassified access=destination vehicle=destination;agricultural bicycle=yes foot=yes moped=yes horse=yes highway=track motor_vehicle=forestry motorcycle=agricultural motorcar=agricultural bicycle=yes foot=yes horse=yes highway=track access=destination motorcycle=destination motorcar=destination bicycle=no foot=yes agricultural=yes highway=track access=agricultural motor_vehicle=agricultural;forestry motorcycle=designated motorcar=agricultural highway=service access=destination motor_vehicle=destination motorcycle=destination motorcar=destination foot=yes highway=residential access=agricultural motorcycle=destination motorcar=destination bicycle=yes goods=destination highway=path access=forestry motor_vehicle=forestry motorcycle=no motorcar=forestry bicycle=no foot=yes horse=yes highway=living_street motor_vehicle=destination motorcycle=destination motorcar=destination bicycle=yes foot=yes highway=cycleway access=yes motor_vehicle=no motorcycle=no motorcar=no hgv=no bicycle=yes foot=official goods=no highway=track motor_vehicle=no motorcycle=no motorcar=no bicycle=designated foot=yes agricultural=yes horse=yes highway=residential access=no motor_vehicle=destination motorcycle=destination motorcar=destination bicycle=yes highway=track vehicle=agricultural;forestry motor_vehicle=agricultural;forestry bicycle=yes foot=yes horse=yes highway=track access=agricultural motorcycle=agricultural motorcar=agricultural bicycle=yes foot=yes horse=yes highway=service access=permissive motor_vehicle=permissive bicycle=permissive foot=permissive horse=permissive highway=residential motor_vehicle=destination motorcycle=destination motorcar=destination bicycle=yes foot=yes -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Examples at https://wiki.openstreetmap.org/wiki/Key:access
On Sun, May 24, 2020 at 11:54:02PM +0200, Colin Smale wrote: > On 2020-05-24 23:16, Mateusz Konieczny via talk wrote: > > > Can you give an example of such untaggable restriction? > > In the UK there are many small roads signed as "Unsuitable for HGVs." > Legally you are allowed to drive your 44T truck down there, but you will > almost certainly get stuck. How do we tell the router? width? maxwidth? It a different attribute than legalese which makes it unsuitable - so tag it appropriate. > There are also many roads signed as "No HGVs except for access." It is > tempting to tag them as "hgv=destination" but that doesn't cover the > case where you are allowed to follow that route for many miles and make > several turnoffs IF you "need access". The current definition of > "access=destination" doesn't allow routers to distinguish between truly > "first/last segment only" and "its fine if you are going to/from this > general area". > Discussion here shows the > http://www.trucknetuk.com/phpBB/viewtopic.php?f=5=140446 Thats a technical difficulty in the OSM Data model which may fill pages. At least in Germany a restriction sign is not a "linear restriction" e.g. is restricting the whole way. Instead you may not traverse the point of the sign. We are currently unable to put this into OSM. A workaround is to put 2 short oneways on top of each other - one of them carrying the restriction - which is in itself a pretty ugly solution - and - this does not work for destination. There are other problems. A destination technically is currently solved by increasing the "cost" in the routing graph. So for example for every meter on a destination road you may travel 20m on others. Which most of the time works pretty well in avoiding the destination roads. It has pretty bad side effects which causes the router to try to send you out of the destination area with the shortest way even producing very long diverts around. Legally this is broken. Legally you may not enter the zone when your destination is not within that zone and there nothing like a distance based penalty within that area. So yes - there is a problem - But not within tagging. Its something routers need to solve. > And then there are all the subtle differences in the semantics of the > vehicle classes, but that's a whole different can of worms... Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Examples at https://wiki.openstreetmap.org/wiki/Key:access
gt; > Is access=private supposed to be incorrect in either case? Its indistinguishable - Thats the problem. A private on a driveway is definitly something which is not verifyable in most cases, whereas the gate in the NPP is. In case of the NPP its a physical restriction, in case of the driveway its more of an emotional one. You cant distinguish them as we tag them the same. You must treat them pretty different if you are UPS - but cant distinguish them. I'd be happy to introduce a new tag for driveways - "drivewayaccess=private" which makes it distinguishable to NPPs. > > So IMHO the advice to tag EVERY driveway with access=private is a very > > bad one. > > > Yes, driveways that are open to general public (shared driveway without gate > or > other restrictions) or to all customers (tourism attraction driveway) should > not > be tagged like a private driveway. For me a service is by itself not for the general public as the service article already states. Tagging it with driveway does make it even less public. It will be not used as through road anyway. So there is a difference between a driveway with and without any signs, gates or fences. If not globally than at least for Germany. So in case this is very different to Poland i would suggest removing the driveway from the access examples alltogether and make it a local issue. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Examples at https://wiki.openstreetmap.org/wiki/Key:access
On Sun, May 24, 2020 at 08:47:38PM +0200, Florian Lohoff wrote: > For me its missing at least 2 points: > > - The "Ground truth" we tag restrictions only when visibly assigned and > verifyable. > - To use access restrictions as simple and minimal as possible. I put these in - I rephrased the pretty strong "You dont need any ground truth" to - "We should follow ground truth and not introduce guesswork" which is in clear line with OSM Best Common Practices. And i rephrased the driveway private road to make it explcitly that not all driveways need an access=private, just if there is a clear intent of the legal entity e.g. owner to make it out of bounds. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Examples at https://wiki.openstreetmap.org/wiki/Key:access
On Sun, May 24, 2020 at 10:50:19PM +0200, Colin Smale wrote: > On 2020-05-24 20:47, Florian Lohoff wrote: > > > - The "Ground truth" we tag restrictions only when visibly assigned and > > verifyable. > > It is sufficient to say "verifiable". It does not always need to be > evidenced by a visible sign - as long as another independent mapper > could (easily) verify its truth. The fact that (in many countries) speed > limits and parking rules change when you enter a settlement means that > these attributes are verifiable without there needing to be an explicit > sign. But these are basically "legal rules" you may find somewhere. I am fine with that. I am not fine with guesswork. "I think the owner allows bicycles but not cars" without any hint of this really beeing the case. You'll open up a huge can of worms if suddenly access tags are not reliable but some Jo mappers guesswork. > > So - people try to overload the meaning of access=private > > with something more like ownership=private. > > Access=private always means you have no "right" of access, and must keep > out unless you have permission from the appropriate authority (be that > the owner of a driveway or the operator of a nuclear power station). > That permission can be explicit (a permit or invitation) or implicit > (delivery drivers etc). Routers frequently apply different rules for the > first and last segments of a route, blocking routing over "private" > roads in the body of the route but not hesitating to use them if they > are the only way to access the start and destination locations. I had the phrasing in our German discussion already. In routing you are either Allowed to use a way Not allowed to use the way Allowed to use the way at the tail/head of a route What is access=private? And if you answer "it depends" - On what does it depend and how does the software know? And how does the software distinguish between ways in a nuclear power plant and a driveway? access=private is mostly excluded for everything for good reasons. For a driveway marking it as service/driveway is everything you need. It has penaltys so its basically the same as destination. If you add a private to a driveway you change the routing availability from destination to no. And i dont think this is what most owners of a driveway would expect. If they dont want people on their driveway by all means the'll put up signs or barriers which is common in some areas of the world. I definitly would be angry if some random mapper adds a access=private to my 1.5km driveway (Which i have) because i want people to be able to reach my house. I had this and it caused 15km+ diverts for people relying on OSM. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Examples at https://wiki.openstreetmap.org/wiki/Key:access
On Sun, May 24, 2020 at 12:10:41PM +0200, Mateusz Konieczny via talk wrote: > I just added some example at https://wiki.openstreetmap.org/wiki/Key:access > and improved existing one. > > Review, and improving edits (or comments here) would be welcomed. > > Deliberately posting to talk to get review also from people less involved in > tagging discussions. > > Thanks to Malenki and Seventy7 for suggesting it (in 2009 and 2010 > respectively). For me its missing at least 2 points: - The "Ground truth" we tag restrictions only when visibly assigned and verifyable. - To use access restrictions as simple and minimal as possible. From my experience access restrictions are currently the most problematic issue concerning routing. People mix in a lot of stuff like ownership, legal, physical and "emotional" aspects to tag access restrictions. This causes a lot of harm to reachability of addresses. For example the German forum fights (with me) for tagging all driveways as access=private disregarding any signs of the will of the owner. So even you dont post additional signs or putting a gate on your driveway the proposal is to tag everything access=private. I dont think thats a good idea as it makes the driveway and the area of the nuclear power plant indistinguishable. So as a delivery like Amazon Logistics, UPS, FedEx and Co you have to ignore access=privates to be able to actually use your driveway, which automatically makes them ignore the power plants service as well. This will be prone to real errors and bad workarounds. So - people try to overload the meaning of access=private with something more like ownership=private. So IMHO the advice to tag EVERY driveway with access=private is a very bad one. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] oneway = no
On Sat, May 23, 2020 at 07:04:07PM +0200, Volker Schmidt wrote: > Aus welchem Grund siehst du das bei Radwegen anders als bei Strassen? > Das Problem ist genau das gleiche. > Dummerweise gibt es keinen tag value "positivly yes".im Gegensatz zu dem > Ansatz missing tag fehlt = tag with default value. > > Ich wuerde dich dringend bitten, wenigstens in Zukunft keine Loeschungen > von "vollkommen redundanten" tags mehr vorzunehmen. Danke im Voraus. Aeh - Das ist ein großer unterschied. Straßen sind zu 99% und mehr keine Einbahnstraßen. Also macht es keinen Sinn die 99% zu taggen sondern die 1% ALLE Straßenbegleitenden Radwege sind aber oneways. D.h. da sind wir vermutlich bei 70-80% die ein oneway sind - daher macht es bei denen die es nicht sind Sinn diese explizit zu taggen. Hier tagge ich die 20% abweichenden zusätzlich zu den 70% die ich eh taggen muss. Einfach Statistik. Und alle default tags nochmal taggen nur damit einige wenige eine Vollständigkeitsstatistik führen können ist auch irgendwie missbrauch der osm tags oder sehe nur ich das so? Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=crossing -> highway=traffic_signals
Hi, On Sat, May 23, 2020 at 04:48:17PM +0200, Volker via Talk-de wrote: > Hat das vielleicht etwas hiermit > https://forum.openstreetmap.org/viewtopic.php?id=69290 > zu tun? Das Proposal ist allerdings > rejected.https://wiki.openstreetmap.org/wiki/Proposed_features/traffic_signals%3Dcrossing_only > Das will ich nicht ausschliessen. Kann es sein das irgendein validator oder QA tool das als Fehler raus wirft und änderungen Analog des proposals empfiehlt? Ich sehe halt Änderungen im routing weil natürlich eine Ampelkreuzung anders als Fußgängerampeln bewertet werden. D.h. bestimmte routen werden "länger" bzw langsamer. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] highway=crossing -> highway=traffic_signals
Hi, ich sehe in den letzten Wochen immer mehr mapper die Fußgängerampeln umtaggen von highway=crossing crossing=traffic_signals zu highway=traffic_signals +++ Gibts da irgendeinen Grund für? Ich halte das für falsch aber vielleicht vertue ich mich da ja auch. Mir ist das nur aufgefallen weil dadurch die travel zeiten im routing hoch gehen weil ein highway=traffic_signals anders bewertet wird als crossing=traffic_signals - Was ja auch richtig ist. Ist das eine Koordinierte aktion? Ist das ein validator der das als Fehler auswirft? Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massenweise Entfernung von oneway=no
On Fri, May 22, 2020 at 03:15:14PM +0200, Volker Schmidt wrote: > Bin durch Zufall auf diesen Changeset > <https://www.openstreetmap.org/changeset/43566283> gestossen, in dem > oneway=no entfernt wurden. > Ich persoenlich setze routinemaessig oneway=no um anzuzeigen, dass ich > geprueft habe, dass die Strasse keine Einbahnstrasse ist. In Verbindung mit > dem Aenderungsdatum ist das nuetzlich in Gegenden, wo Strassenrichtungen > haeufig von den Behoerden geaendert werden. > > Daher meine Fragen: > (1) ist das community consensus in DE, dass oneway=no entfernt werden > sollten ? > (2) falls ja, sollte das nicht als Massen-Edit im Wiki dokumentiert werden? > (Falls ich eine entsprechende Diskussion und Entscheidung verpasst habe, > bitte ich um Nachsicht) oneway=no auf Straßen halte ich für overkill. Für 1% der Straßen die Einbahnstraßen sind (Geschätzt) setzen wir auf 99% ein oneway=no - Weiss nicht ob DAS effizient ist. Ich mache das nicht. Ich "bereinige" das aber auch nicht großflächig. Was anderes ist das auf Straßenbegleitenden Cycleways. Da finde ich ein oneway deshalb spannend weil es eben anzeigt das der Beidseitig genutzt werden kann. D.h. Linksseitiger Radweg ist freigegeben. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gewichtung der Straßen im Routing
On Wed, Apr 29, 2020 at 01:11:32PM +0200, Volker Schmidt wrote: > Ich halte das mit maxspeed:practical fuer eine ziemliche Kruecke. > Habe mich mal umgeschaut, und die meisten Beispiele, die ich gefunden habe, > waren Strassen, wo fast alle relevanten tags fehlten: > lanes, width, surface, incline, oneway, smoothness, lit > Ich halte es fuer besser den Strassenzustand zu beschreiben, und dem Router > zu ueberlassen, was er daraus macht (auch mit der Analyse der Geometrie), > als mit fiktiven Werten eine erwuenschtes Verhalten zu errreichen. > Ausserdem ist der tag selten (1300 in Deutschland und die beschraenkt auf > kleine Zonen, wo offensichtlich jeweils ein mapper in seiner Umgebung alles > damit voll gepflastert hat). > > Um noch mal auf das urspruengliche Beispiel ( Liemekestrasse > <https://www.openstreetmap.org/way/23737060> ) zurueckzukommen. > Wenn der Router eine Strasse trifft mit maxspeed=100 und > motor_vehicle=designated, width=4 dann geht das schief. Die meisten Router > addieren Strafpunkte oder Bonuspunkte. In jedem Fall hat das falsche > tagging den Effekt, das zwei starke Vorteile (100km/Stunde und reserviert > fuer KFZ), den einen Nachteil (schmale Strasse) "ueberstimmen". Falsches > mappen sollte man nicht austricksen, sondern korrigieren. Im vorliegend > Fall waere der lokale mapper anzuschreiben, dass er die Situation vor Ort > kontrolliert und das tagging korrigiert. Ich kann mir nicht vorstellen, > dass eine 4m breite Strasse in DE nicht Geschwindigkeits-begrenzt ist. Ausserhalb geschlossener Ortschaften gilt 100km/h - Damit gilt am Ende auf jedem Feldweg 100 - Nicht das das fahrbar wäre oder auch dem Vorrausschauenden Fahren entspricht. Rechtlich ist das richtig. Und OSRM macht daraus: if width <= 3 or (lanes <= 1 and is_bidirectional) then width_penalty = 0.5 end D.h. wenn die Breite <3m (Also nur eine Fahrspur) oder eben lanes=1 ohne oneway ist dann ist die penalty 1/2 maxspeed - Also in diesem fall 50kmh. Und ich finde das trifft es ziemlich gut. Deshalb kann man die width taggen (Was ohne vor ort hinzufahren und mal nachzumessen oder zumindest mal schritte zu zählen schwer ist) oder eben lanes=1 - Nachweislich ist es nur eine Fahrspur. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gewichtung der Straßen im Routing
On Tue, Apr 28, 2020 at 09:15:39PM +0200, Tom Pfeifer wrote: > On 28.04.2020 17:35, Florian Lohoff wrote: > > Die Frage war wie ihr das mit der relativen Gewichtung von > > Routingalternativen bearbeitet und fixed. > > Es gibt den Tag "maxspeed:practical", der angibt, wie schnell man > realistischerweise auf einer Strasse vorankommt. > https://wiki.openstreetmap.org/wiki/Key%3Amaxspeed%3Apractical > > Auch hierzu das Beispiel Irland - bei der Umstellung der Geschwindigkeiten > von Meilen auf Kilometer pro Stunde hatte man überall, wo das formale > Limit wechselt - typischerweise innerorts 50 und ausserorts 80 - die > rotumrandeten Schilder aufgestellt. Wenn also oben beschriebene > Straße, die sich auch alle paar Meter windet, und gleich der Trecker > um die Ecke kommen konnte, steht da 80 dran, obwohl man sich nur mit > 15 vorsichtig vorantasten kann. Da hilft maxspeed:practical dem Router > zu mehr Realismus. OSRM supported das mit dem :practical nach meinem profile nicht - Den nehme ich seit 2013 für die routing analyse weil schnell und prima scriptable. Wer supported das denn? Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gewichtung der Straßen im Routing
On Tue, Apr 28, 2020 at 05:57:51PM +0200, Volker Schmidt wrote: > lanes=1 ohne oneway=no|yes wird von einigen (auch von mir als moeglicher > Fehler) betrachtet, und ist daher keine gute Idee. Warum? Woher nimmst du diese Erkenntnis? Gibts in irgendeinem Wiki Artikel was zu? Das wäre mir völlig neu. "lanes" beschreibt die Anzahl der markierten! Fahrspuren. D.h. alle Straßen ohne Fahrbahnmarkierungen sind tendentiell lanes=1 - Der lanes Artikel spricht davon das dann auch with benutzt werden KANN bzw das width nützlich sei. > Kennst du die Gegend persoenlich? Ja - Aber nicht mein mapping hotspot - Und es geht mir auch nicht um die millionen Fehler die da rumlungern. Mir sind nur routingänderungen aufgefallen die ich für unsinn halte die durch sparse tagging ausgelöst waren. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gewichtung der Straßen im Routing
On Tue, Apr 28, 2020 at 03:17:16PM +0200, Tom Pfeifer wrote: > On 28.04.2020 14:44, Florian Lohoff wrote: > > Nachdem ich dann die neue grünen teil mit lanes=1 > > versehen habe ist soeben die route zurück geschwenkt. > > Entspricht denn lanes=1 der Realität? > Also der Verkehr in beiden Richtungen teilt sich eine Spur? Wenn du aneinander vorbei möchtest muss einer auf die Bankette - ja - Mindest wenn die ein Trecker oder was breiteres entgegen kommt. Ich frage mich aber warum sich alle an DIESEM konkreten fall hochziehen. Die Frage war wie ihr das mit der relativen Gewichtung von Routingalternativen bearbeitet und fixed. Oder bin ich der einziger der sich sowas systematisch ansieht? Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gewichtung der Straßen im Routing
On Tue, Apr 28, 2020 at 01:12:30PM +0200, Volker Schmidt wrote: > Beispiele? Das war der Schwenk heute morgen. Grün ist neu. Da wird dann der vermeindliche Autofahrer durch eher den Outback geschickt bzw durch die Siedlung (maxspeed=30). Da hatte jemand den dem neuen Grünen teil am westlichen Ende maxspeed=100 getagged. Macht halt wenig Sinn. https://osm.zz.de/routeqa/?rid=187615,203745 Nachdem ich dann die neue grünen teil mit lanes=1 versehen habe ist soeben die route zurück geschwenkt. https://osm.zz.de/routeqa/?rid=203750,203905 Ich weiss aber nicht was das mit der theoretischen Betrachtung von Straßengewichtungen zu tun hat. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Gewichtung der Straßen im Routing
Hi, ich habe gerade wieder so zeugs repariert wo jemand im Aussenbereich auf Straßen die eher zur Erschließung der Streusiedlungen gedacht sind mit einem maxspeed=100 bedacht hat. Natürlich ist das rechtlich richtig aber leider völlig an der Realität vorbei. Das hat natürlich sofort dazu geführt das im routing das als "rat-race" Strecke präferiert hat ggü der breit ausgebauten Landstraße die aber vielleicht ein maxspeed=70 hat. Ich habe jetzt da auf dem Rat-Race strecken ein "lanes=1" hinterher geworfen was im routing (Zumindest OSRM) die erwartete maxspeed halbiert was vermutlich (Bestätigung kommt in 1 1/2 Stunden aus meinem Automatismus) das wieder fixed. Relative Gewichtung von Straßen untereinander sollte ja wenn alles sauber getagged ist in 95% der Fälle die Priorität des "offiziellen" Straßennetzes wiedergeben. Leider ist unser tagging was maxspeed, lanes, shoulder, surface, width angeht ja eher so sparse was das routing ziemlich "kaputt" macht. Wir als OSM wollen ja nicht Leute quer durch die Siedlung schicken wenn es eine Bundesstraße gibt. Wie handhaben hier andere so dinger? Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vergleichsplugin Amt/OSM ? e: Datenqualität open data NRW und OSM
Hola Ludwig und Co,
On Tue, Mar 10, 2020 at 10:11:00PM +0100, Ludwig Baumgart wrote:
> Hallo Otto,
>
> wenn Du als QGIS-ler-Spezialist mit einem Plugin etwas für uns OSM-ler
> entwickeln könntest, fände ich das sehr gut.
>
> Ganz im gleichen Sinn wie Florian und Martin:
>
> Hier in BaWü sind zwar nicht einmal die amtlichen Luftbilder für OSM
> freigegeben, aber es gibt in nahezu jeder Kommune (über deren Rahmenvertrag
> mit dem LGL-BW) die umfänglichen amtlichen Datensätze (NAS-Format für
> PostgisDB) incl. Luftbild. Da wäre ein solcher "Gebäude-Vergleichs-Plugin"
> zwischen OSM-Gebäuden und amtlichen Gebäuden sehr wertvoll.
Am Ende brauchst du da kein großes Plugin.
Mit ogr2ogr bekommst du die NAS Daten in eine Postgis (Das dauert aber
17 Jahre und noch 2 Schneewittchen lang - Was ein ineffizientes Format)
Danach lädst du dir mit osm2pgsql ein pbf des Ausschnittes in dieselbe
Datenbank - Der rest ist SQL.
Mein primäres sql diff ist das hier. Ich sammel mir für jedes ALKIS Gebäude
alle schneidenden OSM Gebäude zusammen (ST_Union) - Dann baue ich da ein
diff drauf (Wenn keine schneiden dann ist mein Diff = 100% des ALKIS Gebäudes)
Die Tabelle ax_gebaeude_diff kopiere ich dann mit ogr2ogr in ein
sqlite. Dann reichere ich die sqlite mit metadaten an (Boundary,
styles etc) und dann schiebe ich die in meine
Visualisierungsgeschichte (https://github.com/flohoff/spatialite-rest)
auf http://osm.zz.de/dbview
select *
intoax_gebaeude_diff
from(
select *,
ST_Area(ST_Transform(diff, 25832)) area,
ST_Area(ST_Transform(alkisgeom, 25832)) alkisarea
from(
select ogc_fid,
gml_id,
coalesce(ST_Difference(geom, building), geom) as diff,
geom as alkisgeom,
building as osmgeomcollection
from(
select g.ogc_fid,
g.gml_id,
g.geom,
ST_Union(p.way) as building
fromax_gebaeude g
left outer join planet_osm_polygon p on (
ST_Intersects(p.way, g.geom) and p.building <> '' )
where ( g.lagezurerdoberflaeche is null or
g.lagezurerdoberflaeche <> 1200 )
group by g.geom,ogc_fid,gml_id
) foo
) bar
) baz
where area > 5
;
ogr2ogr -f SQLite \
-dsco SPATIALITE=YES \
-nln alkisnotinosm \
${BASE}/${OUTPUT} \
PG:"dbname='osm'" \
-sql "select ogc_fid as id, gml_id as gmlid, diff as geom, area,
alkisarea, 'Area ' || trunc(area) || 'm²' as text, 'default' as style from
ax_gebaeude_diff"
Ich mache das ganze processing in docker containern. Also NAS Import bzw
convert in ein pg_dump und das processing gegen OSM Daten.
(NAS Import mache ich nur manuell, OSM diff läuft jede stunde - dann nehme
ich nur den pg_dump)
Ich habe mal meine Pipeline hier abgekippt:
https://github.com/flohoff/nas-osm-diff
Die run-* scripte sind die die dann einen docker spawnen um in dem docker daten
zu prozessieren.
Die process-* scripte laufen dann IM docker.
Ich benutze im Kreis GT auch nur die NAS files weil die zur Verfügung
gestellten Shapes
nur Hauptgebäude enthalten. Also keine Garagen, Schuppen etc was natürlich
Bullshit ist.
Der diff ist auch problemlos gegen shapes zu machen. Die kann man sich
entsprechend
ja auch mit ogr2ogr direkt in eine postgis schieben.
Flo
--
Florian Lohoff f...@zz.de
UTF-8 Test: The ran after a , but the ran away
signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Announcing Daylight Map Distribution
On Mon, Mar 09, 2020 at 05:08:10PM -0700, Michal Migurski wrote: > Hi everyone, > > I’m writing to let you know about a new OpenStreetMap project Facebook > just released. It’s called Daylight Map Distribution. Daylight is a > complete, downloadable preview of OpenStreetMap data we plan to start > using in a number of our public maps: I think its a humble approach to try to identify (un)intentional bad edits. A lot of people try to deal with this. I am doing a lot of QA myself and i look at OSMCha changesets in my greater surrounding on a daily basis. I fail to see a sane technical way of producing consistent map data out of some intermingled data of which some changesets have been flagged/removed. I heard Mapbox is working on this and divide data spatially not as a sequence of changeset. My impression would be that this way you could produce a "nice looking map" but most likely it will break for routing purposes in most horrible ways where ways suddenly are not connected anymore as some changeset inbetween has been withdrawn/rejected. So i'd guess the way you and IIRC Mapbox try to solve the vandalism/bad edit issue is a labour and machine learning intensive task which you cant win. Once you eliminate changesets you fall behind and you pile up inconsistencies. This is, i guess, the reason for your "one shot" dump of your current internal state. So from my perspective the vandalism/bad edit issue will only be fixable if we have some review process (Not that i would suggest one) for strictly sequential changesets where review must be in order and a once rejected/withdrawn changeset can only be requeued not put in that sequential place again. And even then you'll see vandalism sneak by with innocent looking edits or intentional 3rd party validation. So i'd love to hear more thoughts about long term ideas how to solve this in a collaborative manner. OSMCha is probably not the final solution but currently it brings together analysis, be it human or machine learning in a transparent way, not that it currently has an impact on the main OSM database. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Datenqualität open data NRW und OSM
On Fri, Mar 06, 2020 at 10:19:16PM +0100, Martin Koppenhoefer wrote: > im Prinzip, in einem Land mit hoher Mapperdichte wie Deutschland, > sicherlich ja, aber zunächst sind es ja nur Abweichungen, die man > durch den Vergleich der Daten feststellen kann, um rauszubekommen, > welche Version richtiger ist, muss man vor Ort nachschauen. > “Integrieren“ ist sicherlich gut, aber das heißt natürlich nicht blind > ersetzen von allem was wir gemappt haben durch amtliche Daten... Das kann ich nur unterschreiben. Auch das ALKIS hat definitiv Abweichungen von der Realität. Ich sehe die jeden Tag. Was aber Spaß macht ist das ALKIS und derer Veränderungen als Indikator zu benutzen zu sehen wo sich etwas ändert. Zugeteilte Adressen, veränderte, neue, abgerissene Gebäude. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenqualität open data NRW und OSM
On Fri, Mar 06, 2020 at 01:24:46PM +0100, Tobias Knerr wrote: > On 06.03.20 12:42, Florian Lohoff wrote: > > On Fri, Mar 06, 2020 at 11:30:53AM +0100, Otto Dassau wrote: > >> * Könnten/Dürften die Daten NRW genutzt werden, um die OSM Daten > >> flächendeckend z.B. für NRW zu optimieren? > > > > Am Ende nein. Gucken darfst du, aber übernehmen nicht. > > Vor ein paar Tagen wurde im Forum die Neuigkeit verbreitet, dass die > "Geobasisdaten NRW" jetzt unter der Datenlizenz Deutschland Zero stehen, > die meines Wissens mit OSM kompatibel ist: > https://forum.openstreetmap.org/viewtopic.php?pid=779174#p779174 > > Ich bin mir jetzt nicht sicher, ob da die hier diskutierten Daten auch > darunter fallen? Jau - Saucool: https://www.bezreg-koeln.nrw.de/brk_internet/geobasis/opendata/index.html Da steht die neue Lizenz für die WMS Dienste. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenqualität open data NRW und OSM
On Fri, Mar 06, 2020 at 11:30:53AM +0100, Otto Dassau wrote: > Hallo, > > das Thema wurde wahrscheinlich schon häufiger diskutiert, ich habe dazu aber > bisher nichts gefunden. Es geht um den Vergleich zwischen den Daten, die vom > Land NRW bereitgestellt werden und OSM. > > Ich habe hier ein Beispiel abgelegt, um es zu verdeutlichen: > https://www.gbd-consult.de/download/vergl_odnrw_osm.png Ach guck - Sowas ähnliches baue ich auch gerade - Allersdings für den Kreis Gütersloh der Wöchentlich die NAS Daten des ALKIS als OpenData veröffentlicht. > Man sieht, dass die Übereinstimmung der Gebäudegrenzen zwischen OSM und den > roten Linien der NRW Daten im linken Fenster (Bsp: Düsseldorf) gut, im > rechten Fenster (Bsp: Lüdenscheid) nicht so gut ist. Die Qualität scheint > also unterschiedlich zu sein. > > Meine Fragen dazu sind: > > * Könnten/Dürften die Daten NRW genutzt werden, um die OSM Daten > flächendeckend z.B. für NRW zu optimieren? Am Ende nein. Gucken darfst du, aber übernehmen nicht. Das ist leider im Rahmen der INSPIRE umstellungen auf OpenData verloren gegangen (Also unsere Sondererlaubnis) > * Wenn ja, gibt es dazu bereits Ansätze, wenn nein, wie könnten die > aussehen? > > Ich würde gerne wissen, was man als Nutzer und/oder als Kommune, wie > Lüdenscheid machen kann, wenn man OSM gerne nutzen möchte, die Qualität > aber scheinbar nicht so gut ist. Da wir die offiziellen ALKIS Daten nicht nutzen dürfen kannst du wenig machen. Du kannst vielleicht Daten von der Stadt Lüdenscheid bekommen unter einer besseren Lizenz die mit OSM kompatibel ist. Oder vielleicht ist die Lageungenauigkeit auch nur durch abzeichnen von Bing gekommen und wenn man die Gebäude mithilfe der ESRI Daten korrigiert ist der Fehler kleiner. Mich interessiert gerade weniger die absolute Lagegenauigkeit - Mal ein paar centi/decimeter daneben - So what. Mich interessiert wo sich im Gebäudebestand was getan hat. Also Abrisse, Neubauten. Da fehlen dann ganze Gebäude. D.h. ich versuche gerade was zu basteln wo ich mit die "Difference" der Gebäudefläche ansehe und wenn aus dem ALKIS ein Gebäude mehr als X m² nicht in OSM ist gebe ich diese Differenzfläche aus. Im QGis habe ich das schon - Will ich jetzt noch als web view exportieren. So sieht das gerade aus - Das sind neubauten die mal irgendwann grob eingezeichnet wurden - Da fehlen dann jetzt die Garagen z.b. https://silicon-verl.de/home/flo/tmp/2020-03-06-missingfromosm.jpg Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] foot=yes on highway=primary / StreetComplete
On Tue, Feb 18, 2020 at 07:57:28AM +0100, Ferdinand wrote: > Dieser Tag sollte eigentlich nur von street complete hinzugefügt werden > wenn es keinen Sidewalk giebt. Und warum? Nur weil es keinen Sidewalk gibt darf ich trotzdem als Fußgänger die Fahrbahn nutzen? Oder steht da in der StVO mit einem mal das die Fahrbahn nur für Motorisierte KFZ ist? Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] foot=yes on highway=primary / StreetComplete
On Mon, Feb 17, 2020 at 11:11:46PM +0100, Bernhard Weiskopf via Talk-de wrote: > Die Defaults betrachte ich als Vermutung, nicht als gesichert. (default > = in Ermangelung von ...) Aeh das sieht das Wiki und die Datennutzer anders: https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access_restrictions Und primary sieht für foot/bicycle ein yes als default an. Ich halte das taggen dieser defaults für einen bug. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] foot=yes on highway=primary / StreetComplete
Hi, Ich bin gerade über einige Changeset gestolpert in denen StreetComplete foot=yes auf primarys gepackt hat. Mich wundert das so ein bisschen weil grundsätzlich war ich davon ausgegangen das alles ausser motorway als default foot=yes hat. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Cease use of OpenStreetMap/Antifa logo
Hi, On Mon, Feb 10, 2020 at 04:57:40PM +0100, Midgard wrote: > Hi, > > Someone created a mashup[1] between the logos of OpenStreetMap and Antifa, a > collective of militant > groups which are known to use violence. This graphic is distributed on > stickers.[2] Just nitpicking but "militant groups" is a little far fetched. Antifa is the abbreviation for "Anti fascist" and by no means has anything to do with militant activities. Putting the Antifa into the militant left wing edge is polemic of a lot of right wing, facist or nationalist partys in the rise in a lot of European countries. > I'm asking to cease use of this logo. > > I think it's a bad idea to create material that associates OpenStreetMap with > political groups. > I suspect there are also trademark issues with the mashup. I agree that OSM should not by itself get into the trouble of sympathising with any political views. OTOH the idea of Anti Facism should be within OSMs interest as we want to be a welcoming, divers and globally collaborating group of individuals. Facism OTOH is the exact opposite of what the OSM Community wants to be so i sympathise with the idea of parts or the whole of the community opposing facism. https://wiki.openstreetmap.org/wiki/Community_Code_of_Conduct_(Draft) > [1] > https://wiki.openstreetmap.org/wiki/File:2019_OSM_Anarchist_Antifa_logo.svg > [2] > https://wiki.openstreetmap.org/wiki/OSM_Promotional_Material_Programme#Swag_from_Individual_OSMers As already the URLs mention this is not an official OSM position but individuals making mashups. From my POV the mashup is to far from the original to be a serious and clear trademark issue. But - IANAL. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Daten über Restriktionen und Vorrangrouten ?für den Schwerlastverkehr in NRW
On Thu, Nov 28, 2019 at 06:03:55AM +0100, Georg Verweyen wrote: > Hallo zusammen, > > Erst einmal Danke an Tom, dass er die erste einleitenden Worte zur > Einordnung gebracht hat. > > Als ich die Mail von von Herrn Spitzley gelesen habe, habe ich nur > gedacht „Was für eine riesige Aufgabe“. Und ich bin mir tatsächlich > immer noch nicht im klaren, ob wir die Erwartungshaltungen in Deckung > bringen können. Deshalb habe ich es gerade auf die Themenliste für den > Dezember OSM Stammtisch von Bonn gesetzt Ich habe vor Jahren mal das Amtsblatt des Kreises Gütersloh über die festlegung des Gefahrgutstraßengrundnetzes durchgearbeitet und alles getagged. https://f.zz.de/posts/200908121002.openstreetmap_gefahrgutstrassengrundnetz/ So sah das mal 2009 für den Kreis GT und einen klein bisschen nördlich von Bielefeld aus. Mittlerweile ist das ein bisschen in die Jahre gekommen und ich habe auch inkonsistenzen gefunden. Sowas wie hgv=destination und hazmat=designated geht ja nicht. Und es ändert sich auch was - Leider hab ich nie wieder eine neue Fassung des Gefahrgutstraßengrundnetzes für den Kreis gefunden. Oder es gibt scheinbar auch highway=pedestrian und hazmat=designated und andere konstruktionen. Das werde ich in meinem wayproblems layer auch aus. Ich glaube nicht das das Gefahrgutstraßengrundnetz durch Fußgängerzonen geht. Hier so ein paar Beispiele: way=51924597 problem="hazmat=designated with hgv=no is suspicious" way=51924599 problem="hazmat=designated with hgv=no is suspicious" way=565285675 problem="hazmat=delivery is not in known value list" way=639771859 problem="hazmat=designated with hgv=no is suspicious" way=644805366 problem="hazmat=designated on highway=living_street is suspicious" way=665809563 problem="hazmat=designated with hgv=no is suspicious" way=68654334 problem="hazmat=destination with hgv=no is suspicious" way=712332156 problem="hazmat=designated with hgv=no is suspicious" way=71745922 problem="hazmat=delivery is not in known value list" Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] destination:ref auf *_link?
Hi, ich analysiere so ein bisschen refs auf Höherklassigen Straßen. Dabei hat mich ein user darauf aufmerksam gemacht das *_link kein ref sondern ein destination:ref tragen sollten. Ich habe versucht das im wiki nachzuvollziehen und scheitere ein wenig. Das scheint zum einen eine Deutsche sonderlocke zu sein, und zum anderen ist das original destination:ref nur ein proposed artikel. Die ganzen highway=*_link Artikel enthalten nichts davon. Lediglich die Deutschen Varianten enthalten was davon. Was ist denn da jetzt so der "Standard" - Alles was *_link ist trägt ein destination:ref aber kein ref? Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] name:suffix & name:prefix (de)
On Tue, Oct 29, 2019 at 06:07:31AM +0100, Friedrich Volkmann wrote: > On 29.10.19 03:33, Robert Kaiser wrote: > > Damit kann ich mich anfreunden. Mit Dingen wie "Marktgemeinde" oder > > "Bezirk" im "name"-Tag dagegen nicht. > > Das ist halt die Sicht eines Programmierers und keines Geografen. > Programmierer sind gewöhnt, dass zwischen den Daten und dem User eine > mächtige Software steht, welche die Daten auf ausgeklügelte Weise > aufbereitet. Das ist in OSM aber nicht der Fall. Die Daten landen mehr oder > weniger unverändert beim User. Programmierer-Grundsätze sind hier > schlichtweg fehl am Platz. Das hat was mit Datenhaltung zu tun. Wenn du einmal Daten ineinander rührst gehen sie halt nicht wieder auseinander. Wenn du einmal information löscht kannst du sie nicht wieder hinzufügen. Wenn du "Multikultistadt Langstrumpf an der I." hast kriegt die Maschine das nicht mehr auseinander. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] name:suffix & name:prefix (de)
On Mon, Oct 28, 2019 at 10:37:39AM +0100, andreas wecer wrote: > Am Mo., 28. Okt. 2019 um 09:48 Uhr schrieb Thomas Rupprecht < > rupprecht.tho...@gmail.com>: > > > Was haltet ihr von diesen Varianten?: > > > > official_name=Marktgemeinde XYZ > > name=XYZ > > > > oder > > > > name=Marktgemeinde XYZ > > short_name=XYZ > > Das wurde schon hier vorgeschlagen und ist das aktuelle im Osten > verbreitete Schema: > http://osm-talk-at.1116557.n5.nabble.com/Re-Talk-at-Grenzen-td270.html#a337 > > Im übrigen löst das auch das von Florian angesprochene Problem, dass > name:suffix/prefix weder vernünftig dokumentiert ist, noch nicht einmal in > Nachbargemeinden des selben Kreises konsistent verwendet wird und Auswerter > dann daraus wieder irgendwie einen offiziellen Namen basteln wollen, obwohl > es genau dafür schon einen Tag mit official_name gibt. Ich habe da überhaupt kein problem mit :suffix und :prefix - Wenn es eine Bildungsregel gibt wie man zum offiziellen Namen kommt. Was bei mir Praktikabel funktioniert ist name + name:suffix. name:prefix enthält dann eben so Dinger wie Marktgemeinde, Stadt, Kreis etc. Und das die eine Gemeinde ein "Halle (Westf.)" im name und Werther ein name=Werther und name:suffix="(Westf.)" hat ist für mich okay. Sollen halt unterschiedliche dinge in der Karte auftauchen und da wird nur name gerendet. Der mapper black_bike hat gerade in Deutschland Großflächig admin boundarys umgetagged und hat da ein name_prefix= dazu getagged. Also im moment wird das Chaos gerade signifikant größer. Zitat aus dem Changeset in dem ich nachgefragt habe: "Der Tag name_prefix (oder wars name:prefix?) dient oft dazu lokale Persönlichkeiten oder Besonderheiten zu kennzeichnen. So z.B. Lutherstadt, Kolpingstadt, Rosenstadt, Bundesstadt oder Hansestadt. " Ich blicks nicht mehr und im moment scheint so jeder zu machen wie er meint und es gibt eben keine Dokumentation wie es wirklich sein soll. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-de] Moratorium beim Flächen verkleben
On Tue, Oct 22, 2019 at 09:59:10AM +0200, Martin Koppenhoefer wrote: > Bitte nicht da-sch Doch - und er macht ungehindert weiter. In den letzten Stunden wieder 10 Changesets mit massiver verklebeaktivität. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Moratorium beim Flächen verkleben
On Tue, Oct 22, 2019 at 11:13:43AM +0200, pbnoxious via Talk-de wrote: > On 22/10/2019 10.41, Florian Lohoff wrote: > >> Da ist die Ecke - Alles was rot leuchtet sind Verklebungen: > >> > >> > https://osm.zz.de/dbview/?db=wayareaconflicts-mv=wayareaconflict#54.12473,11.69829,14z > > Wenn ich die bisherigen Diskussionen richtig in Erinnerung habe, war das > Ergebnis, dass es für beide Seiten schon Argumente gibt (mit iirc einer > Tendenz von mehr Leute gegen verkleben), aber auf jeden Fall nicht > systematisch Gegenden von einer Variante auf die andere geändert werden > sollten. Der Entwurf einer Policy von Frederik spricht sich klar GEGEN das Verkleben aus. Aber egal ob nun die eine oder andere Weise. Es war ganz klar angesagt hier keine Mass Edits auszuführen um noch schnell "zu gewinnen". > Der von dir angeführte Link zeigt aber nur, dass da Wege und Flächen > sich Nodes teilen und nicht, dass das systematisch in den letzten Tagen > gemacht wurde. Um hier nicht wieder die gleiche generelle Diskussion > für/wider gemeinsame Nodes zu führen, finde ich das eher eine schlechte > Visualisierung. Siehe initiale Mail - Da hatte ich EINEN Changeset exemplarisch verlinkt. Geh einfach die Changesets von da-sch durch - Jeder zweite verklebt massiv vorher unverklebte Flächen. Ich habe die angefangen im OSMCha als "bad" zu markieren. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Moratorium beim Flächen verkleben
On Tue, Oct 22, 2019 at 10:35:33AM +0200, Martin Koppenhoefer wrote: > Am Di., 22. Okt. 2019 um 10:29 Uhr schrieb Florian Lohoff : > > Da ist die Ecke - Alles was rot leuchtet sind Verklebungen: > > > > https://osm.zz.de/dbview/?db=wayareaconflicts-mv=wayareaconflict#54.12473,11.69829,14z > > > wobei man bei Feldwegen ggf. unterscheiden muss, ob das "echte" Wege sind > (also z.B. außerhalb der Parzellen/Flurstücke), oder welche, die auf > privatem Ackerland verlaufen. Mache ich persönlich zwar nicht, wäre m.E. > aber akzeptabel wenn man in solchen zweiteren Situationen die Wege auf dem > Ackerland verlaufen lässt. Bei Straßen ist das allerdings nie der Fall. Wenn der nur DRÜBER läuft wird das nicht rot. Rot wird das hier nur wenn es Nodes gibt die in einer area (typischerweise landuse) und einem weg sind. D.h. erst wenn du die beiden Äcker rechts und links des Feldweges da dran klebst wird das rot. Und selbst das halte ich für falsch. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Moratorium beim Flächen verkleben
On Tue, Oct 22, 2019 at 09:59:10AM +0200, Martin Koppenhoefer wrote: > Bitte nicht da-sch > Ich erinnere mich auch so, dass man bis auf weiteres weder im großen Stil > diese Probleme der falsch verbundenen Flächen fixt, noch weitere solcher > Fehler durch Vergrößern bereits an ihrer Grenze endender Flächen hinzufügt. > Vielleicht ist die Info einfach nicht angekommen, liest ja nicht jeder > überall mit. Auswertung für MV ist durch: Da ist die Ecke - Alles was rot leuchtet sind Verklebungen: https://osm.zz.de/dbview/?db=wayareaconflicts-mv=wayareaconflict#54.12473,11.69829,14z Und obacht - er lädt nur 1000 Segmente - Steht rechts. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Moratorium beim Flächen verkleben
Hi, ich bin ja einer der Streithähne beim Flächenverkleben und bevor ich jetzt wieder Diskussionen anfange mit einem User (da-sch) will ich hier einfach drauf hinweisen. Es läuft da gerade ein "Blutbad" in MV - da-sch löst Flächen die derzeit getrennt gemapped sind auf und verklebt die mit den Straßen - Und das in ganz großem Stil. Ich hatte die Diskussion eigentlich so verstanden das wir da ein Moratorium haben und nicht hier in die eine oder andere Weise massenweise umgetagged wird? Hier ein Beispiel: https://www.openstreetmap.org/changeset/76015440 Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Postalische Eigenständigkeit / admin boundarys
On Thu, Oct 17, 2019 at 02:03:37PM +0200, Georg Feddern wrote: > Weder andere noch schöne - eher ein Gegenargument: > Denn dieses Zusatztagging hilft vielleicht bei solch eindeutigen > Sonderfällen - aber es bleiben eben immer noch die 0,8 % der anderen > Sonderfälle, wo Randerscheinungen einfach dem postalischen Zustellbereich > der Nachbargemeinde zugeordnet werden, die sich nicht so leicht kennzeichnen > lassen. > Lohnt sich dann für diese 20%-Erfolgsrate solch eine Sonderlocke? > Und wenn, dann bin ich voll bei Dir: Für reines QA-Tagging bitte einen qa: > Namensraum statt allgemeiner keys bitte! > > PS: Kann man das nicht durch einen zusätzlichen QA-Check gegen die > PLZ-Relation (mit postal_code und name) erkennen/prüfen/false-positiven? Da bin ich auch fein mit - Wo und wie man das abbildet - qa: namespace o.ä. Fände das halt nur doof "Ausnahmenlisten" zu pflegen ausserhalb von OSM - Dann muss das jeder der sich damit beschäftigt wieder selber machen. Wenn man das irgendwo ablegen kann. Das das mit dem addr:city und dem name auf dem Admin Boundary vielleicht in Deutschland super funktioniert aber woanders kaputt geht ist mir schon klar. Die postal_code relation werte ich ja auch aus - postal_code ist ja identisch für Harsewinkel und Marienfeld 33428 - Aber eben der addr:city nicht. D.h. der postal_code validiert super - Nur der city name nicht ;) Deshalb ja auch die mail - mehr an die die sich mit dem QA auf Adressen beschäftigen. 1) Wo gibts noch so postalische Sonderlocken? 2) Was ist der schlauste Weg das abzulegen? 3) Wie machen andere das. Ich kenne halt keine weitere postalische Eigenständigkeit. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Postalische Eigenständigkeit / admin boundarys
Hi, ich mache so einiges an Adress QA und u.a. überprüfe ich ob das addr:city zu dem name (und name:suffix) auf dem admin_boundary mit dem admin level 6 bzw 8 passt. Das geht auch in 99% der Fälle gut und funktioniert. Es gibt aber einige Gemeinden die im Zuge von Eingemeindungen ihre postalische Eigenständigkeit erkämpft haben. Z.b. ist hier 33428 Marienfeld genannt (gehört zu 33428 Harsewinkel) Marienfeld ist eigentlich "nur" ein Stadtteil von Harsewinkel. https://osm.zz.de/dbview/?db=addresses-nrw=addresserror#51.95246,8.28361,14z Jetzt suche ich irgendeinen weg wie man das erkennen kann oder halt entsprechend taggen. D.h. auf dem admin_boundary mit dem admin_level 10 von Marienfeld ein addr:city=Marienfeld hinterlassen z.b. https://www.openstreetmap.org/relation/9609627 Jemand ne andere schöne idee. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreuz Werl - seltsame Spurnutzung
On Tue, Oct 15, 2019 at 10:19:28PM +0200, Martin Koppenhoefer wrote: > > > sent from a phone > > > On 15. Oct 2019, at 19:56, Florian Lohoff wrote: > > > > Dann müsste ja am Anfang der Parallelfahrbahn ein Schild zum Aufheben der > > Geschwindigkeitsbeschränkung stehen. > > > > Und nein - Da steht nix: > > > > https://www.mapillary.com/map/im/s0p8LimdBltpy1uTD4gmtA > > ich würde es auch so sehen dass man auf der Parallelen die Strecke > nicht verlässt, während wer ganz rechts raus fährt verlässt die > Strecke Ich habe mal weil es scheinbar zumindest hier keinen Dissens gibt das maxspeed=none auf der Parallelfahrbahn entfernt. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] name:suffix & name:prefix (de)
On Wed, Oct 16, 2019 at 09:54:21AM +0200, vari...@mailbox.org wrote: > Dazu ein von mir gern gemachter Hinweise auf die "Bitte keine > Abkürzungen verwenden" - > https://wiki.openstreetmap.org/wiki/DE:Names#Abk.C3.BCrzungen_.28nicht_verwenden.21.29 Ich mache seit 12 Jahren OSM - Ist mir alles durchaus bekannt. > Ich sitz gerade hier und frage mich, was Westf. heissen soll. > Westfurt? Westfahlen? Westfehlen? Die Router und Renderer können das Westfalen - Ohne h. > eh abkürzen, wenns denn sein muss. Ich hätte das in name_short=* > gepackt, aber ich habe gerade gesehen, dass Westf. ja als > name:suffix=* eingetragen wird, da geht das dann natürlich nicht... > > Ich bin für "Gemeinde" und solche sachen in name:suffix=*, aber eben > ausgeschrieben. :D Und nein - Es ist keine Abkürzung - Ist offizieller Namensbestandteil und steht so auch auf dem Ortsschild. https://www.mapillary.com/map/im/lLaSkicxrU9t8Hqgt_nQvQ Ich wollte aber eigentlich nicht bedauerliche Einzelfälle diskustieren sondern das wenn sich talk-at auf eine nummer mit suffix/prefix einigt diese Regeln aufschreibt weil es das woanders auch schon gibt (Sieht das hier als Beispiel) und es leider bisher da keinerlei Doku zu gibt wie aus name, name:suffix und name:prefix der offizielle Name gebildet wird. Und ICH - also auswerter und QA Software Author fände es super wenn es da einen eineinheitlichen weg geben würde. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] name:suffix & name:prefix (de)
On Wed, Oct 16, 2019 at 02:06:59AM +0200, Robert Kaiser wrote: > Florian Lohoff schrieb: > > Die Stadt heisst "Werther (Westf.)" bzw "Halle (Westf.)" - In der Karte > > sind "Werther" und "Halle (Westf.)" zu sehen. Das ist aber eher Gewohnheit > > weil es ein "Halle" gibt aber kein zweites Werther. > > > Für mich klingt das aus einem ganz anderen Grund als prefix/suffix komisch, > und zwar weil Abkürzungen in OSM an sich vermieden werden sollten - und > "Westf." klingt stark nach einer Abkürzung. Ist laut Ortssatzung der offizielle Name. Also nicht selbst abgekürzt sondern Buchstabengetreu aus der Satzung bzw dem Ratsbeschluss übernommen. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] name:suffix & name:prefix (de)
Hi, ohne in die Diskussion eingreifen zu wollen. Es wäre schön wenn das mal Dokumentiert werden würde woher auf den Boundarys die name:prefix und name:suffix kommen und wie der richtige Weg ist aus diesen Bestandteilen den offiziellen Namen zu generieren. Ich mache für ein paar Adressvalidierungen in einem teil von Deutschland so Klimmzüge das ich gerne aus dem admin boundary Daten den "Offiziellen" Namen der Gemeinde hätte der dann auch im addr:city auftaucht. Hier die comments aus meinem Code: // // Build official name - No documentation on the osm wiki for this // // Examples show: // // name:prefix=Stadt // name=Werther // name:suffix=(Westf.) // // Or // // name:prefix=Stadt // name=Halle (Westf.) // Die Stadt heisst "Werther (Westf.)" bzw "Halle (Westf.)" - In der Karte sind "Werther" und "Halle (Westf.)" zu sehen. Das ist aber eher Gewohnheit weil es ein "Halle" gibt aber kein zweites Werther. D.h. der name + suffix bilden den Offiziellen namen. name:prefix enthält "nur" die Kategorisierung. Ich habe aber nirgends Doku dazu gefunden wie das gemeint ist - Habe ich nur reverse engineered. Deshalb - wäre schön wenn es dazu Doku gäbe. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-de] Kreuz Werl - seltsame Spurnutzung
On Tue, Oct 15, 2019 at 01:06:24PM +0200, Roland Olbricht wrote: > Hallo Michael, [ ... ] > Verbindungsrampen werden oft mit Entwurfsgeschwindigkeiten von 40 km/h > bis 60 km/h konzipiert. Schaut man sich die Kurvenradien der Kleeblätter > am Autobahnkreuz in Werl an, so sind dort auch eher 40 km/h oder weniger > konzipiert worden. Ein explizites Schild gibt es an solchen Kurven nur > vereinzelt (speziell Werl kenne ich nicht, bei anderen Autobahnkreuzen > gibt es beide Fälle), aber OSRM hat meines Wissens auch keinen > Präprozessor, der Kurvenradien auf Geschwindigkeitsgrenzen umrechnet. > Damit bleibt außer dem Tag highway=motorway_link aus Sicht der Routers > kein besserer Indikator. In Werl ist das Thema ja nicht das Kleeblatt sondern die Parallelfahrbahn. Und IMHO ist die eben wenn vorher ein maxspeed=signals gilt, dann gilt nicht plötzlich maxspeed=none auf der Parallelfahrbahn. Dann müsste ja am Anfang der Parallelfahrbahn ein Schild zum Aufheben der Geschwindigkeitsbeschränkung stehen. Und nein - Da steht nix: https://www.mapillary.com/map/im/s0p8LimdBltpy1uTD4gmtA Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreuz Werl - seltsame Spurnutzung
On Tue, Oct 15, 2019 at 01:23:53AM +0200, Martin Koppenhoefer wrote: > > > sent from a phone > > > On 14. Oct 2019, at 15:00, Florian Lohoff wrote: > > > > Merke: Eine Geschwindigkeitsbegrenzung gilt bis sie aufgehoben wird (Und > > eine Einmündung hebt sie nicht auf) > > die Geschwindigkeitsbegrenzungen gelten für die „Strecke“, d.h. wenn man die > Strecke verlässt gelten sie nicht mehr. Praktisch sind an allen Stellen wo es > zu Unklarheiten kommen könnte normalerweise Schilder. Welcher teil der Autobahn ist denn die Strecke? Es ist ja eine Parallelfahrbahn die denselben Anfangs und Endpunkt hat. Mir würde das jetzt schwer fallen da eine eindeutigen Strecke zu identifizieren bzw deren abweichung. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreuz Werl - seltsame Spurnutzung
On Sun, Oct 13, 2019 at 10:24:33AM +0200, michael spreng wrote: > Ich interpretiere das leicht anders. routing.openstreetmap.de braucht > einen anderen Regelsatz: > https://github.com/fossgis-routing-server/cbf-routing-profiles > > Die auf/abfahrt ist mit maxspeed=none gemappt, welches in 140kmh > übersetzt wird. > maxspeed=signals hingegen ist dem Profil unbekannt, und es wird der > weltweite default für motorway von 90kmh angenommen. > > Wäre es nicht sinnvoll, die auf/abfahrten mit demselben maxspeed zu > tagen wie die parallele Autobahn? > > Was für eine Geschwindigkeit sollte vom routing bei signals angenommen > werden? Das werden wir dem "router" schon sagen müssen. Eine allgemeingültige Antwort gibts da ja nicht. Die Frage ist ist da tagsüber nichts und zur Rushhour 100? Oder ist das zwischen 100 und 130? Vermutlich macht es Sinn das mit maxspeed:signals= zu taggen. Dann hat ein Automat die Chance das rauszufinden. Ich stelle da aber mal eine ketzerische Frage. Woher kommt das maxspeed=none auf der Parallelfahrbahn? Vor dem Abzweig gilt ein maxspeed=signals - Wenn die abzweigt gilt das weiter - Das ist ja nicht mit einem mal aufgehoben. Man könnte Argumentieren das das für die neu auf die Autobahn einbiegenden gilt aber wir betrachten hier den fall der durchfahrenden. Daher plädiere ich dafür die Parallelfahrbahn ebenfalls auf maxspeed=signals zu taggen bzw das maxspeed=none _mindestens_ zu entfernen es sei denn am Begin der Parallelfahrbahn steht ein Schild das die bestehende Geschwindigkeitsbegrenzung aufhebt. Merke: Eine Geschwindigkeitsbegrenzung gilt bis sie aufgehoben wird (Und eine Einmündung hebt sie nicht auf) Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Kreuz Werl - seltsame Spurnutzung
Hi, ich habe eben meine Routenüberwachung ein wenig ausgedehnt auf teile der A44 und A1 Dabei ist mir der hier aufgefallen: https://www.openstreetmap.org/directions?engine=fossgis_osrm_car=51.5349%2C7.9014%3B51.5332%2C7.8828#map=17/51.53369/7.89198=N Wenn man von ost nach west auf der A44 durch das Kreuz Werl routet wird die Nebenfahrbahn präferiert - In Gegenrichtung ist das nicht so. Grundsätzlich scheint die zu gehen - nur eben schlechter bewertet. Hab ich so spontan nicht verstanden. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vehrkehrszeichen 250
On Thu, Oct 10, 2019 at 05:29:23PM +0200, Martin Koppenhoefer wrote: > Am Do., 10. Okt. 2019 um 16:35 Uhr schrieb Florian Lohoff : > > > Ich bin dagegen access restrictions nach Gefühl oder interpretation > > einzutragen. Wir tragen das ein was da und verifizierbar ist. > > > > Der Algorithmus kann sich dann das richtige daraus bilden. > > +1, eine Straße die an einem See endet könnte auch noexit=yes sein, und > trotzdem könnte jemand mit einem Amphibienfahrzeug auf dem Wasser > weiterfahren. > Oder jemand mit einem flugfähigen Fahrzeug überfliegt die Schranke ;-) noexit=yes müsste auch eigentlich qa:noexit=yes sein - Das ist nur für die validatoren. Das hatte ich ja sowieso mal vorgeschlagen das wir für die qa/validator annotation einen namespace wie qa:* nehmen. qa:noname=yes qa:noexit=yes Und dann eben listen haben mit annotations um false-negatives zu annotieren für alle möglichen checks. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vehrkehrszeichen 250
On Thu, Oct 10, 2019 at 12:23:47PM +0200, Sebastian Dicke wrote: > Hallo, > > > im Wiki (DE:Verkehrszeichen_in_Deutschland) wird für das deutsche > Verkehrszeichen 250 angegeben, dass man die betroffenen Straßen/Wege mit > vehicle=no taggen soll. In der Straßenverkehrsordnung steht dazu > allerdings: „Krafträder und Fahrräder dürfen geschoben werden.“ Sollte > man solche Straßen/Wege deshalb nicht eher mit vehicle=no, > bicycle=dismount, motorcycle=dismount, mopded=dismount und mofa=dismount > taggen, um diese Vorschrift abzubilden? Außerdem könnte das beim Routing > helfen, wenn Router lieber ein Stück Fußweg einplanen als den Fahrer > einen großen Umweg zuzumuten. Multimodale router ;) Du must ihm halt beibringen das ein Radfahrer auch zum Fußgänger werden kann - Aber vielleicht nicht auf treppen. Und nein - Das steht kein Schild "Radfahrer absteigen" sondern "Gesperrt für Fahrzeuge aller art". Ich bin dagegen access restrictions nach Gefühl oder interpretation einzutragen. Wir tragen das ein was da und verifizierbar ist. Der Algorithmus kann sich dann das richtige daraus bilden. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu OSM-IDs
On Thu, Oct 10, 2019 at 11:43:42AM +0200, Martin Scholtes wrote: > Hallo, > > die ID´s werden hochgezählt und nicht neu vergeben, da sonst ja die > history i-wann kaputt geht. Aeh ja - für NEUE Objekte wird die nicht wiedervergeben. Die API erlaubt es dir aber gelöschte Objekte wiederzubeleben dann kann die ID wieder auftauchen. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fragen, Anregung eines Neulings
On Wed, Oct 02, 2019 at 02:58:16PM +0200, Roland Olbricht wrote:
> Sehr geehrter Herr Mehl,
> nach den Routing-Regeln
> https://github.com/fossgis-routing-server/cbf-routing-profiles/blob/master/car.lua
> schaut, dann findet man, dass
>
> avoid = Set {
> [...]
> 'construction',
> 'proposed'
> },
>
> d.h. es wird in der Tat die Route von routing.openstreetmap.de nicht
> genutzt, weil "construction=yes" gesetzt ist. Hier wäre jetzt die
> Einschätzung gefragt, ob das Tag "construction=yes" gerechfertigt ist.
> Aus der Erfahrung und Beschreibung auf
> https://wiki.openstreetmap.org/wiki/DE:Key:construction
> liest man, dass das Tag nicht verwendet werden sollte (sondern
> "highway=construction" + "construction=motorway", wenn und nur wenn die
> Fahrbahn unbefahrbar ist).
Meist sind die construction=XYZ überbleibsel von einer "Ehemaligen
Baustelle". D.h. das highway= tag wird korrigiert wenn die Baustelle
durch ist, aber jemand vergisst das construction=XYZ tag. Damit
ist das für OSRM nicht nutzbar, in der Karte sieht man das aber
nicht weil highway beim rendering über construction=XYZ steht.
Flo
--
Florian Lohoff f...@zz.de
UTF-8 Test: The ran after a , but the ran away
signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] boundary=administrative ohne admin_level
Hi, ich bin eben beim prozessieren von Adressen über 2 Boundarys gestolpert die als boundary=administrative ohne admin_level eingetragen sind: Mittlerer Oberrhein https://www.openstreetmap.org/relation/898410 Region Stuttgart https://www.openstreetmap.org/relation/377632 Ich vermute das beide nur für die TMC Geschichten existieren oder? Eine Verwaltungsgliederung gibt es auf der ebene ja vermutlich nicht. Deshalb frage ich mich warum die ein boundary=administrative tragen. type=boundary sehe ich ja noch ein Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Spielregeln fürs Tagging
Hi Roland, On Tue, Sep 10, 2019 at 06:43:17AM +0200, Roland Olbricht wrote: > Hallo zusammen, > Mängel im Informationsfluss > > Zwar sind viele Teile von OpenStreetMap gut übersetzt, > aber die Tagging-Dokumentation hat spürbare Mängel. Bei einer Stichprobe > von 10 Tags sind zwar per Tag zwischen 2 und 18 Sprachen gelistet > worden, aber nur wenige der Übersetzungen sind vollständig und aktuell > (in der Stichprobe 2 für Deutsch, 3 für Französisch). Hier wäre mal zu klären ob die Wiki Seiten in !=en_GB überhaupt die führenden Seiten sind und die Landessprachen nur Übersetzungen. Defakto ist das heute nicht so. Jede Landessprache enthält beliebige Anpassungen die zum Großteil nur Partikularinteressen oder Verständnis ohne breiten Konsens darstellen. Wenn wir denn annehmen das en_GB die Führende Sprache ist sollten wir uns drauf einigen das Abweichungen davon auch als solche markiert werden und nicht jeder da irgendwas in die Landessprachlichen Seiten rein schreibt. > Ein anderes Defizit ist, dass Tag-Dokumentationen auf den Wiki-Seiten > auch dann erheblich geändert werden können, wenn das Tag längst breit in > Gebrauch ist. > > Es kommt zudem ebenso vor, dass ein Tag ohne jegliche Dokumentation > eingeführt wird. Wenn dies durch normale Mapper passiert, ist dies > üblicherweise langsam genug um das Tag deuten zu können; so können > Imports oder Organisiertes Editieren die De-Facto-Bedeutung eines Tags > substantiell verschieben, unabhängig davon ob es verbreitet, > dokumentiert oder beides ist. Ich glaube ich hatte mich da vor >10 Jahren schonmal zu geäussert das bei der Dokumentation im Wiki nicht wichtig ist was ein Tag darstellt sondern das eine klare Abgrenzung zu anderen Tags wichtig ist. Das ist ein wenig besser geworden aber eben nicht Strukturiert. Ich verweise da auf die immer wieder aufflammenden Diskussionen zum Thema track/service oder service/residential oder residential/unclassified oder auch tracktype= etc etc. > Bedarf nach mehr Struktur > > Die Tag-Übersetzungen mischen sich mit einem anderen Problem: > verschiedene Features können sehr unteschiedlich in verschiedenen > Regionen aussehen. Z.B. sehen ein highway=primary und > highway=unclassified gegenüber highway=track in Deutschland deutlich > anders aus als in Island oder dem ländlichen Afrika. Es passiert > schnell, dass lokale Unterschiede nur in die Übersetzung der jeweils > dominanten Sprache eingehen, obwohl z.B. die Tagging-Anforderungen in > den französischsprachigen Ländern Belgien, Kanada und Niger spürbar > verschieden sind. Umgekehrt gibt es keinen sinnvollen Grund, die > Tagging-Regeln in Brüssel pro Häuserblock zu ändern. Das Thema Track/Unclassified etc vor allem wenn wir in Länder kommen die nicht alles Asphaltieren eine andere Geschichte. Hier ist IMHO das Problem das wir zwar "Map whats on the ground" haben aber das bei Straßen eben nur teilweise gilt. Hier mappen wir die Nutzungsart die ja nicht sofort sichtbar ist und attributieren nach der physischen Beschaffenheit. Das ist eben nicht intuitiv. Für einen "Stadtmenschen" der einen Ausflug aufs Land macht ist dann alles hinter dem Ortsschild ein track. Für jemanden der da wohnt ist klar das da der Postbote fährt, der Schulbus und da noch 100 Leute Wohnen und das das kein Track sein kann. Da kann eben das was hier nach track aussieht in Madagaskar auch eine primary sein. Diese Differenzierung habe ich im Wiki so nie klar gefunden - Das ist überliefertes Kopfwissen von >10 Jahren OSM. Und das wird auch in den Diskussionen auf den Mailinglisten immer klar das das so nicht jedem klar ist. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] admin_level=8 name != addr:city - Postalische Eigenständigkeit
Hi, wir haben hier ein Dorf das hat sich mal die postalische Eigenständigkeit erkämpft (Schon mehreren Dekaden). Der Wikipedia Artikel erklärt das: https://de.wikipedia.org/wiki/Marienfeld_(Harsewinkel) Jetzt habe ich das korrekt umgetagged weil eben die Adressen nicht 33428 Harsewinkel sondern 33428 Marienfeld sind. Marienfeld liegt im admin_level=8 von Harsewinkel und ist formal nur ein Stadtteil. Der Vergleich mit anderen Adressbeständen ist jetzt richtig und grün, dafür fällt mein eigener Adressvalidator auf die Backe der überprüft ob in addr:city auch der name vom admin_level=8 (bzw 6) steht - Da ist jetzt alles rot :) Die Frage ist ob es hier eine Liste gibt von Postleitzahl/Ortsnamen die eine ebensolche postalische Eigenständigkeit haben. So als Ausnahmenliste für den Validator. Andere Beispiele wo es andersherum gelaufen ist (Eingemeindungen): https://ol.wittich.de/titel/1607/ausgabe/5/2019/artikel/13124159-OL-1607-2019-12-5 http://www.seeburg-city.de/Amtsbote/2004JanFeb/Postleitzahlen.htm https://www.stadt-zoerbig.de/de/archiv/aenderung-der-postalischen-bestimmungsortangaben-fuer-den-ort-06369-schortewitz-2419.html Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSRM-talk] maxspeed and speeds in car.lua
On Fri, Aug 16, 2019 at 02:15:07PM +0200, Silvia Oviedo wrote: > Hi everyone, > > I would like to have your input regarding this: > > In OSM there is tag: maxspeed. In my case, I find that the majority of the > primary roads have 30mph ~ 48 kph as a max speed. In the car.lua, I find > that the highway speed that has been set primary is 65 kph. Is the speed in > the OSM tag taken into consideration? I understand that the speed table is > accessed by WayHandlers.speed() function but I am not sure what's the > effect of WayHandlers.maxspeed(). Hi, maxspeed, width, oneway, lanes and surface tags are used to determine the weight/cost/estimated speed to travel segment - A lanes=1 without any oneway will typically assume its typically speed is something like halve of the maxspeed. But the whole issue is more complex as lanes and maxspeed may carry :forward/:backward suffixes etc. So the car.lua with the help of lib/maxspeed.lua and others do that estimation. If there is no maxspeed osrm has some assumptions for road classes. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
Re: [OSM-talk] Chaos Communications Camp 2019?
Hi, On Sun, Aug 18, 2019 at 07:17:49PM +0200, Rory McCann wrote: > (Not to self: don't press send too early!) > > I wonder if anyone else is going to the Chaos Communications Camp next week? > Is there going to be much OSM stuff/people there? I'll be there, hit me up > if you wanna meet up. :) > > https://events.ccc.de/camp/2019/ I am here too - DECT # 2200 Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Facebook mapping highways using AI in collaboration with OpenStreetMap
On Mon, Jul 29, 2019 at 10:41:17AM +0200, Michael Kugelmann wrote: > Am 25.07.2019 um 11:36 schrieb Florian Lohoff: > > And IIRC it was about a > > collaboration with the local community in Thailand which their first aim > > was. > I just remember that the "collaboration" in Thailand some time ago > (might be years) was quite poor: by using AI generated data simply > thrown into the database they destroyed a lot of craft-mapped data. But > unfortunately I am not aware how this evolved and about the current > situation. That's the background why I would be very cautious about such > "collaboration statements". The point was not about quality but about announcement and speaking up publicly about it. And Facebook did - loud and clear for everyone to hear - Quality issues are a seperate issue. I am pretty shure that AI can not replace human, on the ground, observation. It can help identify places to visit. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Facebook mapping highways using AI in collaboration with OpenStreetMap
On Wed, Jul 24, 2019 at 09:07:01PM +0100, Nuno Caldeira wrote: > so grateful of "The project is a collaboration with OpenStreetMap (OSM)". I > might have missed the announcement, can anyone pinpoint me the link of such > collaboration being announced? > Hope they find some spare time in the future to add the attribution on the > maps on their website and apps. #priorities They had a talk about this in Milano at the SoTM - And IIRC it was about a collaboration with the local community in Thailand which their first aim was. You might want to check the video on their talk last year. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSRM-talk] Visualising the hierarchy
On Fri, Jul 05, 2019 at 01:08:12PM +0100, Richard Fairhurst wrote: > Hi all, > > Is it in theory possible to take OSRM's CH graph and visualise, say, the > "top 10%" of routes? > > In other words, I'm interested in creating a map which shows the highest > order of contractions - the routes which are most likely to be followed. > Obviously I'll have to write some code, but would appreciate a few general > pointers. I'd be interested too. Currently i am selecting nodes on the routeable grid manually to do long term route stability monitoring for QA reasons. So i get mails when routes change around me. (Every 2 hours i process routes) Selecting these grid nodes automatically by "importance" would be helpful to do this kind of monitoring on a wider range. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
[Talk-de] Datenstand OSRM/Graphhopper Main Page
Hi, weiss jemand ob man den Datenstand des OSRM und Graphhopper Instanz auf der Hauptseite irgendwo sehen kann? Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] boundarys / river als boundary / admin_level?
On Tue, May 21, 2019 at 12:05:41AM +0200, wambac...@posteo.de wrote: > Jetzt mal Butter bei die Fische: > > Hast du den Export der Boundaries überhaupt ausprobiert? Ich könnte auch > in den Logfiles nachsehen, aber warte erstmal ab. Ich habe bei dir schon so viel Boundarys exportiert ;) Das mit dem buffer ist mir bisher nicht aufgefallen. > "Komische" Poly-Files hab ich bei meiner Software übrigens schon lange > nicht mehr erlebt.( muss ca 6-7 Monate her sein, dass es da mal ein > Ticket zu gab) Das http://polygons.openstreetmap.fr/get_poly.py?id=73347=0.02-0.001000-0.005000 wirft komische polys. > Was brauchst du denn genau? > - Mehr als eine Grenze auf einem Schlag? No Problem. Jaja - ich kenne das und benutze das reichlich wenn ich wieder irgendwo shapes oder polys brauche. Bisher war mir nicht aufgefallen das ich einen buffer setzen kann. > Und natürlich alles bei Bedarf mit frei definierbaren Buffern ohne > Überlappungen. Siehst du - den hatte ich noch nicht entdeckt. Dann hast du ja alles was mein Herz begehrt .. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] boundarys / river als boundary / admin_level?
Hi, On Mon, May 20, 2019 at 09:32:25PM +0200, Jochen Topf wrote: > > besorgt - Problem ist das entgegen der Doku die durch > > das ST_Simplify doch kleiner werden und schneiden können. Muss man > > also im Buffer entsprechend vorsorgen. Ausserdem entstehende da durchaus > > mal seltsame Multipolygone. > > Wenn Du alles innerhalb einer Grenze haben willst, kannste das auch mit > "osmium extract --polygon" machen und die Grenze direkt aus OSM nehmen. > Wenn Du dann noch die "smart"-Strategie benutzt, dann ist auch die > Grenze selbst garantiert drin. Vereinfachte Grenzen machen das Ganze > etwas schneller, aber nicht viel. Und dann musste Dich nicht mit Buffern > oder so rumärgern. Ich habe halt hier für meinen ganzen Auswertungsramsch diverse sub PBFs von Deutschland die ich derzeit mit osmupdate/osmconvert update und neu beschneide. Dafür brauche ich halt polys. osmupdate/osmconvert ist da ein wenig eigenwillig was das ausschneiden angeht. Daher ist mir dann OWL/Regierungsbezirk Detmold um die Ohren geflogen. Ich würde ja einfach auch osmium umstellen in der pipeline aber da fehlt mir das mit dem dem automatisch update eines pbfs d.h. download der change files. Ich will doch einfach nur ein geographisches .pbf auf dem aktuellen stand halten. Und das "consumerdevice" um das zu machen ist halt osmupdate mit dem -B poly und schon läuft das für doofe. Die 50+ Jobs werfe ich dann einfach alle 2 Stunden mir slurm in die Luft und der scheduled mir die durch mit den dependencies. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] boundarys / river als boundary / admin_level?
On Fri, May 17, 2019 at 07:22:06PM +0200, wambac...@posteo.de wrote: > Moin > > Am Ende war es vieles - poly von download.geofabrik.de der an einer > > winzigen stelle einen node schneidet einer boundary. > > osmupdate/osmconvert mit dem poly schneiden dann da einen teil der > > boundary weg. > > Die Poly-Files der Geofabrik sind fast alle händisch erstellt worden, > daher einfach und relativ schnell. Wenn sich aber eine Grenze verändert > haben sollte, kann das (nie wieder angefasste) Poly-File schon mal > falsch sein. > > Mein Tip: / > /- https://wambachers-osm.website/boundaries// > > - bpoly mit einem Buffer von 1-2 km wählen und dann sind die > *tagesaktuell*. ;) Da geht nen buffer? Das habe ich wohl übersehen. Habe mir jetzt bei http://polygons.openstreetmap.fr/get_poly.py?id=73347=0.02-0.001000-0.005000 besorgt - Problem ist das entgegen der Doku die durch das ST_Simplify doch kleiner werden und schneiden können. Muss man also im Buffer entsprechend vorsorgen. Ausserdem entstehende da durchaus mal seltsame Multipolygone. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] boundarys / river als boundary / admin_level?
On Fri, May 17, 2019 at 08:36:07AM +0200, Jochen Topf wrote:
> > und wenn Du die Relationen und deren Member evtl. rekursiv mitfilterst?
> > Oder nur die Relationen mit members?
> > Nur die ways klappt natürlich in dem Fall nicht, aber da kann man dem
> > Osmium keinen Vorwurf machen.
>
> Osmium kannste eh keinen Vorwurf machen, wenn dann Osmosis :-)
>
> Florian: Warum nimmste nicht einfach Osmium, das ist auch noch
> einfacher:
>
> osmium tags-filter detmold-regbez-latest.osm.pbf a/boundary=administrative -o
> output.osm
osmium steckt noch nicht so in den fingern. Und so zeugs brauche
ich dann einmal in 5 Jahren ;) Und meine zeugs was ich versucht habe zu
debuggen ist auch libosmium basiert und ich vermutete den Fehler erst
da.
Am Ende war es vieles - poly von download.geofabrik.de der an einer
winzigen stelle einen node schneidet einer boundary.
osmupdate/osmconvert mit dem poly schneiden dann da einen teil der
boundary weg.
Seltsamerweise ist die boundary bei mir jetzt heile, jetzt wo ich
auf den weg auch ein boundary=administrative gepackt habe. Das hier ist
der code den ich verwende. Wollte noch hinterhersuchen warum das
kaputt ist.
AreaIndex boundaryindex;
osmium::TagsFilter boundaryfilter{false};
boundaryfilter.add_rule(true, osmium::TagMatcher{"boundary",
"administrative"});
osmium::area::MultipolygonManager
boundarymp_manager{assembler_config, boundaryfilter};
AreaIndex postcodeindex;
osmium::TagsFilter postcodefilter{false};
postcodefilter.add_rule(true, osmium::TagMatcher{"boundary",
"postal_code"});
osmium::area::MultipolygonManager
postcodemp_manager{assembler_config, postcodefilter};
osmium::relations::read_relations(input_file, boundarymp_manager,
postcodemp_manager);
Flo
--
Florian Lohoff f...@zz.de
UTF-8 Test: The ran after a , but the ran away
signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] boundarys / river als boundary / admin_level?
On Thu, May 16, 2019 at 08:04:48PM +0200, chris66 wrote: > Moinsen, > > > Die Fragen die sich mir jetzt stellen: > > > > - Sollen alle ways die eine boundary darstellen ein > >admin_level/boundary=administrative unabhängig von ihrer relation > >tragen? > > Sie *dürfen* die Info tragen, als Kompatibilitätskrücke für Anwendungen, > die Probleme mit Relationen haben. Der Punkt ist das auch die Dokumentation kaputt ist - Es wird halt im Wiki das dieses osmosis --read-pbf file=detmold-regbez-latest.osm.pbf --tf accept-ways boundary=administrative --used-node --write-xml output.osm Grenzen extrahiert - und das ist falsch. Es exportiert eben Wege ohne boundary=administrative nicht. Damit sind die Grenzen kaputt. (Dafür werden andere Objekte exportiert die nichts mit boundaries zu tun haben) > > - Bei Flüssen - verdoppeln der Wege (übereinander) oder > >zusätzliche tags auf dem river way? > > Wenn der Fluß tatsächlich per Gesetz die Grenze darstellt, dann > kommt er in die Relation, eine zusätzliche Linie wird dann nicht > gezeichnet. Der Fluß von 1970 stellt die Grenze dar. Das ist vermutlich heute nicht mehr die Flußmitte. > Üblicher ist es allerdings eine Grenze parallel zum Fluß einzuzeichnen. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] boundarys / river als boundary / admin_level?
Hi, ich suche seit ein paar Monaten sporadisch nach einem Fehler in meinem Addressextrakt das bestimmt boundary polygone mit libosmium nicht "parsebar" sind, bzw die an verschiedenen Stellen kaputt sind. Meine Arbeitshypothese war bisher das das poly zu klein ist und deshalb die boundary (Kreis, Stadt) nicht mit drin ist. Heute habe ich mir dann mal das mit osmosis auseinander geschnitten und gefiltert und im josm geladen. osmosis --read-pbf file=detmold-regbez-latest.osm.pbf --tf accept-ways boundary=administrative --used-node --write-xml output.osm Dabei ist mir aufgefallen - Da fehlen Stücke in der relation. Die sind wenn ich die via API lade aber da. Die Stücke die fehlen sind Teile bei denen die Boundary ein Fluß ist. Hier ist (war) in der Boundary nur der Fluß drin der keine Tags wie boundary=administrative/admin_level trägt, diese sind ausschließlich in der relation. Ich habe den weg jetzt dupliziert und entsprechend admin_level und boundary=administrative da hinterlassen. Die Fragen die sich mir jetzt stellen: - Sollen alle ways die eine boundary darstellen ein admin_level/boundary=administrative unabhängig von ihrer relation tragen? - Bei Flüssen - verdoppeln der Wege (übereinander) oder zusätzliche tags auf dem river way? Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] iD invents nosquare=yes for buildings which should not be squared
Hola, On Thu, May 09, 2019 at 06:00:20PM -0400, Jmapb wrote: > This strikes me as a pretty bad idea. I map in NYC where we have lots, > lots, lots of nearly-square buildings with official footprints imported > from the city's open data initiative. When a mapper not familiar with > the history here gets a message from iD (which, to many mappers, is > indistinguishable from getting a message from OSM itself) encouraging > them to square a building, they'll do it because it seems like the right > thing to do. So the official, highly-accurate footprints are lost. And > adjacent buildings with shared nodes are also distorted. I agree on this. Its a bad idea for nearly square buildings to complain on them. Not everying is 90° - Not even in Germany where we love rectangular things. But the point is that i'd like a generic way to to qa/validation hinting. I just sent a similar mail in in a similar thread on the German mailinglist. I'd like to see qa/validation hinting tags be more organised: qa:rectangular=no qa:exit=no qa:name=no qa:housenumber=no or the list form: validation_hint=noexit;noname;norectangular;nohousenumber So every validator could have the "suppress check XYZ" on this object. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The ran after a , but the ran away signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
