As an OpenStreetMap contributor this looks weird. Some names are off from what is recorded in OpenStreetMap. I wonder if…
…and sure enough. This app uses one of those moronic map styles which doesn't just use the names for places in the OpenStreetMap database, but also draws them for Wikidata. Great. Those often suck for use on a map, because they tend to include stuff like 'Province X' for a province named 'X', and because the translations stored in Wikidata are often archaic or plain wrong.
The argument the developers who use the wikidata IDs stored in many place name objects to draw in 'missing' translations is that this is surely better than just showing the local name, but this completely misses that in OpenStreetMap name data is already really quite accurate, whereas Wikidata…
As an OpenStreetMap contributor I am not interested in having to keep two databases up-to-date to get names (exonyms and endonyms) to show up correctly. I know a number of developers are pushing this dumb solution, but it is hurting the project more than it is helping.
Screwups happen all the time. For example in Mapbox basemaps Skorki (some village in Poland) was both:
- transalated as Dermaptera (which incidentally are called skorki in Polish)
- shown at totally inappropriate low zoom level because of the previous point (presumably that Wikipedia article was more linked to or had much more languages, which could be used to decide importance rank)
Map labels are complicated and Wikidata is (in general) a better place than OSM to sort that out on the data level.
Consider all the various *name* tags in OSM and how they are (mis-)used to please specific renderers and geocoders. E.g. do you apply (semi-)standard abbreviations of street names or do you write names in full so that they fill the map? It's fuzzy in OSM: https://wiki.openstreetmap.org/wiki/Abbreviations
(I'm all for everyone using the map style that works the best for them - after all, it's open data and open source.)
If a name tag is broken in OpenStreetMap, I can fix it in OpenStreetMap. If a name label is broken in Wikidata, I now have to fix it there as well, and get into edit wars with folk from Wikipedia who use different rules for naming things. So not only are there now two places to fix bugs, there are also two sets of sometimes conflicting policies for naming things. This is because for Wikipedia (which is Wikidata's sister project and has a large influence on it) it may make sense to call the Belgian district of Luxembourg 'District Luxemburg' in English (which is what OSMApp does via Wikidata), but on a map this region should just be labelled 'Luxemburg' (if using English), or preferably just 'Luxembourg' (the endonym). That it is a Belgian district, and not the neighbouring country can be made sufficiently clear by styling and geography.
After all, you don't expect the literal label 'New York City' for the city and 'New York State' for the US state on a map; just 'New York' for both, with styling and size indicating which is which. Any map which does want to render these names with their classification can do so by adding '(city)' or '(state)' to the label if they want to. It just shouldn't be part of the name in the data source.
Map labels are complicated, so leave that complexity to a project which deals with map data; i.e., OpenStreetMap.
This is a discussion more about data vs. maps, there are data purists in OSM as well. So the correct way to do it according to a large portion of OSMers would be to write out the full name.
Using the full names isn't to 'fill the map', it's because the process of going from full name to abbreviation has a lot less ambiguity than going from abbreviation to full name.
Seems the search box is tripping on that (not considering places on North 14th Street for a search like N 14th St).
The full names will be too much in some cases, and there is no abbreviation algorithm that will work everywhere (OSM is a global project). Similarly, "N 14th St" has no meaning in most of the world.
Hence, it's complicated and not "moronic" e.g. to make use of Wikidata for labels and to use external datasets to improve geocoding.
OSMAnd uses the data from OpenStreetMap itself, and doesn't add any labels from Wikidata when a translation is missing. This is good, because a place name without an explicit name in some other language (i.e., most villages worldwide) won't get some made up name entered on Wikipedia and picked up in Wikidata automatically at some point as they are sister projects.
Not sure if this is directly related but all province names in Belgium are displayed in Dutch, even in the French speaking regions. Waals-Brabant or Provincie Namen, for example.
Another criticism I would make is that different levels are displayed the same, for example in France I can see both "Pas-de-Calais" and "Hauts-de-France" in the same style, at the same time, although one is part of the other.
I noticed Namen/Namur too. That is one where the label seems to be drawn from Wikidata instead of using OpenStreetMap data which has the names correct for each language.
For the city Namur though, it's the French name that is displayed.
And for some reason, the province of Luxembourg becomes "District Luxemburg", which seems to suggest it's Dutch, but the Dutch name would be "Provincie Luxemburg".
Luxembourg itself (the country) does have districts, but this is the Belgian province, not a district of the country of Luxembourg.
I think Switzerland has the same kind of problem but with German being used for most names.
Municipality of Bled... in the middle of the forrest... who the hell searches for "Municipality of bled" and wants to be pointed to a forrest? But somehow, it's probably the middle of the polygon of the actual municipality, and the label is put there and visible even when very zoomed out (along with other municipalities,... but not city names, like actual Bled - https://osmapp.org/#8.33/46.3350/14.1244 )
My town has three McDonald's. It only finds one of them and then suggests ones which are hundreds of kilometers away. Organic Maps finds all of them without problem.
Major place names in Japan are romanized with the Japanese readings, but minor places use Mandarin readings. For example, a nursery school in Yokohama called 野毛山幼稚園, which is read Nogeyama Yōchien, has the label yě máo shān yò zhì yuán [1].
MagicEarth (which seems to be a MagicLane product; https://www.magicearth.com/) is my daily driver navigation app. I prefer it over Google maps for everything routing related. The only thing Google is better at is showing me relevant metainformation about places (when is this restaurant open? What is this doctor's telephone number and website?), and that's the only reason I'm keeping maps on my phone.
I wish, but like I said below, it's not developped anymore. The company got bought by the french cloud company OVH. There are multiple complaints of stale OSM data in the github issues.
Let's hope they want to make a public and open source map part of their europaen google alternative.
OsmAPP is my take on creating a universal OpenStreetMap app for broad public. It should be as easy to use as Google Maps, including clickable POIs and featuring as much of OSM data as possible. I want to educate the user about wikipedia-like experience of OSM, thus edit is possible even for anonymous visitors. It is has still a long way to go ;)
- Big thanks to Maptiler which processes raw OSM data and provides the vector tiles. https://www.maptiler.com/
- Geocoding is done by Photon API which allows autocomplete. The main OSM sites uses Nominatim API which can't. https://photon.komoot.io/
Also thank you very much for featuring OsmAPP here, perhaps someone will find it useful. :-)
PWA is experimential feature, it lets you add it on homescreen, but nothing more. It is still online web app. See https://osmapp.org/install For mobile we have already several great native apps (OrganicMaps, Osmand, Mapy.cz).
That's not a knock against the app, but something you can actually fix - this would use the OSM backend, and adding your parent's address would take all of ten minutes if you care to do so.
This app's search is clearly not the same as the one on openstreetmap.org
On openstreetmap.org I found my address with no issues - I typed the address in the search box, and got a pointer on the map showing me where it is.
On OsmApp, the same exact query resulted in more than 19,000 results and the app proceeded to highlight them all on the map, which effectively means it's impossible to actually locate the address.
You are missing the point. If you do this commercially and have that need, you usually have a separate geocoding. This data can not be combined with OSM unless it is already freely available. The point is that the data in OSM is freely useable in what ever way you want to as long as you publish the data used to create your maps.
There are no available map data that allow this except Openstreetmap.
Can't find my own address and I even edited OSM maps to add it a quite some time ago. Zooming in on the map and there it is. Hmmm... not a good start at all.
Could you try with https://photon.komoot.io, after zooming out to a bbox that includes your place (because the demo search locally) ? Or directly using their API ?
I believe there is some bug in Osmapp's photon handling (it's the API that powers their search field).
Most buildings in OSM aren't actually tagged with numbers. (A lot of houses aren't even marked as existing buildings in my experience.) It should be have their street at least, but adding building numbers is just too time-consuming for outside of cities it seems.
It would be nice if it opened on your current location, or at least a map with a button to do that. It's an annoying step to have to search to see a map. Regarding the content, it seems to be missing some useful POIs that are visible in Organic Maps, such as gates and stiles
…and sure enough. This app uses one of those moronic map styles which doesn't just use the names for places in the OpenStreetMap database, but also draws them for Wikidata. Great. Those often suck for use on a map, because they tend to include stuff like 'Province X' for a province named 'X', and because the translations stored in Wikidata are often archaic or plain wrong.
The argument the developers who use the wikidata IDs stored in many place name objects to draw in 'missing' translations is that this is surely better than just showing the local name, but this completely misses that in OpenStreetMap name data is already really quite accurate, whereas Wikidata…
As an OpenStreetMap contributor I am not interested in having to keep two databases up-to-date to get names (exonyms and endonyms) to show up correctly. I know a number of developers are pushing this dumb solution, but it is hurting the project more than it is helping.