OpenStreetMap

MarkusHD has commented on the following diary entries

Post When Comment
Nonsense values of shop= key 2 months ago

Don't take it too serious. I did understand the purpose of your example, I just explained why "gift" was a bad choice. Since you very much emphasizes consistent and clear tagging, I think it is perfectly fine for a short nitpicking. I didn't want to start a needless discussion about that specific key.

No, fuel and payment are not "completely similar" to tagging product groups in a supermarket. If you navigate to a fuel station, but you cannot use the offered fuel for your motor vehicle, this station is entirely useless for you and might even be problematic for your further tour. If you arrive at some shop without cash, but it doesn't accept your debit card, then this shop is entirely useless as well. But if you visit a supermarket, which doesn't offer bread and juice, you may still choose apples and beer to satisfy thirst and hunger.

Don't get me wrong. Despite my comments I might even agree with parts of your statements.

Nonsense values of shop= key 2 months ago

"Gifts" is a bad choice in this discussion. What is a gift? You can buy any article as a gift for someone - from a cup to a car. You can even buy an article in a shop=gifts for yourself, then it is no gift anymore.

Now rejecting the "car" example and assuming we have a similar view about what a gift is in this context: A more or less small object, which an average person can carry on its own and from which the majority of people think it would be a good idea for use as a present, sometimes if they just have no better idea. And I'm sure this view also only applies to sort of modern areas in the world, so it is still kind of a local assumption for an international project (even if it's not bound to national flavors). Now the particular articles, and let it just be article groups or categories, are such a big variety that shop=gifts is in no way better than or different from shop=supermarket.

Nonsense values of shop= key 2 months ago

You talk about searchability. But natural language, which you call inconsistent for tagging, is exactly the language people use for searching.

MAPS.ME is now an editor 3 months ago

I can confirm the stats: Today a new mapper in my neighbour town. First edit with MAPS.ME, a few subsequent with iD.

Preparing a map for the Garmin nüvi 205t 5 months ago

I use Lambertus' maps on Garmin Dakota 20 and Nüvi 300.

Just tested the address search, which I don't need often: Streets can be found without problem, but house numbers only if the street does not contain umlauts.

Does it work for you with maps from Computerteddy or frikart.no when using a street without umlauts instead of "Lothstraße"? Or maybe "München" already is the problem here.

Rifugio Fontana Mura + sentiero Gta 418 5 months ago

Hi Flavio, the user blogs are intended to be used for writing about interesting stuff around OSM, not for commenting each individual changeset.

Mapping Andhra University College of Engineering (Andhra Pradesh, India) using Field Papers: 5 months ago

And as Omnific wrote, drawing several instead of single buildings per changeset is nice for logical connection and easier for review.

Mapping Andhra University College of Engineering (Andhra Pradesh, India) using Field Papers: 5 months ago

Regarding your changes around http://www.openstreetmap.org/#map=17/17.72916/83.32262

The geometry of the buildings often is wrong (e.g. http://www.openstreetmap.org/way/388816430) and inaccurate and never aligned nicely (out of square). For properly mapping buildings with holes have a look at http://wiki.openstreetmap.org/wiki/Relation:multipolygon

Also I guess the entered names should not be names for most cases, see http://wiki.openstreetmap.org/wiki/Names#Name_is_the_name_only Use the description-key or try to find an ordinary tag, maybe at http://wiki.openstreetmap.org/wiki/Key:office

If the buildings containing "hostel" in the name are indeed a hostel, then why don't you tag it as such?

This does not seem like good promotion for job selection.

personal mapping links 6 months ago

Thanks for the thorough clarification. I wasn't aware of the fact that the collected user diaries were introduced after the user diary. Since I started following about 2 years ago, I never considered the user diaries to be personal diaries, but to contain topics interesting for a wider audience, probably mostly for mappers. The German translation of "User Diaries" on the website is "Benutzer-Blogs", which retranslates to "User Blogs". So from this view, personal entries are comparable to spam.

What I called "user page" above might correctly be called "profile page", then it also won't get confused with the "Wiki user page". The Wiki user page is of course the best place for personal notes like these, better suitable than the simple profile page I suggested first. It also includes history, so nothing could be lost by accident. But you have to log in separately for it. OSM documentation like tag descriptions is only one part of the Wiki. I have seen several profile pages or Wiki user pages containing personal stuff like link lists. The Wiki also offers proper possibilities for organizing your references and links. I can't imagine how to efficiently find and reuse the relevant content from diary entries and comments, which are just sorted chronologically.

I won't comment the idea of adding these links to the OSM map data or notes :)

To clarify the pages, but mine are not yet exemplary regarding the content: Profile page and Wiki user page.

personal mapping links 6 months ago

Please do not misuse the user blog for this. You could add those links to your user page for example.

OSM braucht ein neues openstreetbugs 6 months ago

Ich glaube nicht, dass die geringe Anzahl an Hinweisen, wie ich es auch in meiner Gegend empfinde, auf die Notes-API zurückzuführen ist, sondern eher auf die Integration in Anwendungen. Oder es gibt tatsächlich zu wenige Lücken oder Fehler in den von den Anwendern am häufigsten genutzten Daten (Adressen, POI-Namen), mit Sicherheit werden viele Details aus den Daten einfach nicht verwendet. Ich verstehe deine Schlussfolgerung auch nicht: Was hat automatisiertes Eintragen von Hinweisen mit Apps zu tun? Über Apps, die die Notes-API unterstützen, kann manuell vom Anwender ein Hinweis erstellt werden. Das schreibst du doch selbst über OsmAnd.

Ich habe mir gerade verschiedene Hinweise in meiner erweiterten Umgebung angeschaut. Die wenigsten ließen sich auf reine Anpassung von Tags beschränken und oft sind die richtigen Tags dann nicht angegeben. Viele Hinweise sind allgemeiner gefasst und erfordern ein Anpassen der Geometrie, Anlegen von Objekt(en) oder Bearbeiten mehrerer Objekte. Es wird also immer auch eine Möglichkeit geben müssen, formlos Fehler zu berichten. Es scheinen aber auch einige anonyme Hinweise von Mappern zu stammen und nicht von reinen Nutzern. Dass aber OSM Notes nur für Leute mit OSM-Kenntnis gedacht ist, ist schlicht falsch. Oder warum braucht man für "$HIER existiert $DIESES Problem" Wissen über OSM? Ist alles nur eine Frage der Einbindung in Anwendungen.

Der Unterschied zu Google Maps ist, dass du bei OSM die Daten problemlos selbst eintragen kannst und keinen Antrag stellen musst. Anwender, die mit dem einfachen Fehlerreport über die Notes-API nicht glücklich sind, sind vermutlich bereits Zielgruppe für einfache OSM-Editoren. Durch deine beschriebene Bug-API würde daraus ein Tag-Editor ohne direkte Datenübernahme in die OSM-Datenbank entstehen. Etwas zwischen Fehlerbericht und OSM-Editor. Bräuchte man dann eine parallele Datenbank? Oder würden die Daten doch in der Datenbank landen, nur mit speziellen "Bug"-Tags. Viel Aufwand für einen meiner Meinung nach seltenen Anwendungsfall.

Ein neuer Notes-Status "lokales Wissen nötig" wie oben beschrieben könnte hilfreich sein für den von dir geschilderten Einsatzzweck.

Nicht erreichbare Webseiten kann man mit Keep Right finden. Es ist nicht sinnvoll, alle Arten von Qualitätssicherungs-Tools in die Hauptseite zu integrieren, denn Komplexität ist auch ein ernsthaftes Problem. Die Wiki-Seite Quality assurance sollte das Problem mit der Fragmentierung doch ausreichend lösen, wenn man sie erstmal kennt.

OSM braucht ein neues openstreetbugs 6 months ago

Wann warst du das letzte mal auf OpenStreetBugs? Die Seite ist offline und wurde schon vor über 2 Jahren durch OSM Notes abgelöst.

Č. Těšín, vložení lesního mokřadu 6 months ago

I don't speak Czech, but the photo made me curious. After automatic translation, I think I got the message :)

download 6 months ago

Try searching the OSM Wiki.

10.000 broken Turn_Restriction in the OSM Planet File 6 months ago

https://wiki.openstreetmap.org/wiki/Quality_assurance lists them all, but you still have to be aware about it or find that site.

Missing Dam in Germany 7 months ago

There is no consensus about which of the two kinds of mapping is preferred, it also depends on the specific case. Usually I draw these duplicated ways instead of splitting the way and having to create a relation (e.g. for a lake as in this case).

In enhanced OSM editors like JOSM you can find and select all ways sharing nodes with other ways using the middle mouse button. Maybe this is not possible in iD, I don't know.

Missing Dam in Germany 7 months ago

The dam was already existing since more than 4 years, just without the name: https://www.openstreetmap.org/way/105671446

Now there are two dams, the one above and your new one, which enclosed nearly the whole lake (because the untagged way you mentioned was merely used as outer boundary for the lake relation) before your second edit correcting it: http://www.openstreetmap.org/way/353892535

shops as closed-Way building outlines, but also as Nodes in the center? about 1 year ago

The main problem does not seem to be the POI tagging style (node vs. way), but the ignorance of existing POI data and strange explanations (at least I did not understand it at all) to justify this duplication.

I don't want to misdirect the discussion, but want to add that if tagging the POI as separate node I put the address on both the POI node and the building. Yes, duplication, but not comparable to POI duplication. Nominatim didn't inherit the building address, but guessed from the nearest street, which failed in some cases - this may have changed meanwhile, I don't know. Practically it's the same reason as for adding more address data than just housenumber and street: reliability without hoping the data consumer does it right.

Schnalles Hafen about 1 year ago

Willkommen bei OpenStreetMap! Kommentare zu den Änderungen wären allerdings in den Changesets besser aufgehoben, die wurden bislang alle kommentarlos gespeichert.

Interesting OSM Find of the Day over 1 year ago

This town had been moved and changed to a post office in the same changeset. In fact all changes by this user are totally insane, I have reverted them. Maybe he should be contacted.