View Single Post
Posts: 1,414 | Thanked: 7,547 times | Joined on Aug 2016 @ Estonia
#5
Originally Posted by otsaloma View Post
I had a chance to try your server. My observations:
  • libosmscout is no masterpiece of cartographic rendering -- upsidedown labels, all kinds of things overlapping -- but I guess that was to be expected.
  • There's a huge difference in rendering time between using a Mapzen metro extract for the Helsinki region and a Geofabrik extract for the whole Finland. So, your desire for users to be able to have databases of arbitrary regions instead of country extracts makes sense from a speed standpoint as well. With a Mapzen metro extract, the rendering time is surprisingly fast -- it's very usable!
  • The large tile size seems fine. I doubt we need the smaller ones.
  • The search seems very particular about the query format. e.g. "Erottaja" works, but "Erottaja, Helsinki" doesn't, "Tukholmankatu" works, but "Tukholmankatu 3" doesn't.
  • The "admin_region" field in search results and thus the description field in Poor Maps is often empty. I can't conclude from the results when or why.
  • The Nearby search seems to work fine, expect for the missing region data, which is a known problem. The raw OSM data is really bad for this though -- it's incomplete, outdated and very particular about how exactly POIs are tagged.
  • libosmscout as a masterpiece: To my understanding, its constant optimization of speed vs quality. Label rendering is considered as an expensive part in tile rendering and there might be issues with it. If you have upside-down labels then note that this is unexpected and we should raise an issue in libosmscout developers list or github. An example tile would help (if you could provide server URL that would be of help too).
  • difference in rendering times: Sometimes, there are corner cases that could make rendering slower than it should. For example, in Estonia, the rendering was majorly slowed down due to the handling of ferry lines with the ferry between Rostock and Helsinki increasing rendering time by order of magnitudes. This case was solved by @Karry. I don't know if you are hitting something similar. How long do you have to wait on the phone for a 1024x1024 tile to be rendered? There are also some messages printed in stdout by the library that are not displayed in Events of the server. I have converted Finland map and can check out on the phone if you would send me the zoom level and rough coordinates. Then we can see if there is something peculiar with Finland. But true, rendering is far from instant. That's were caching is helping a lot.
  • Tile size: yes, large are probably the way to go.
  • Search of Erottaja and admin_region: see below
  • POI: that's maybe can be improved if I'll manage to find a way to get admin_regions for that. But yes, OSM data limitations are inherited by the server as well.

The search is implemented in two parts: search for location and search for any free text in the map. While the first is case insensitive, the free text search is case-sensitive.

The search results can be distinguished easily right now by presence (location) or absence (free text) of the admin_region field in the reply.

For location search, you have to add frequently an area where you search. When you search for Erottaja, you'll get the first response from the location search with

"admin_region": "Erottaja, Iitti, Päijät-Häme, Etelä-Suomi, Etelä-Suomi, Suomi"

The replies from the free text search find all objects that have the search string in object title. So, if you were searching for a bus stop in Helsinki then you get it as a part of free text search that can find an object with the name Erottaja, but its not recorded as "Erottaja, Helsinki" in that database. I don't know why the bus stop is not available in location search, maybe we should ask in libosmscout list.

As for Tukholmankatu, again all can be explained and the search can be guided. When you just use Tukholmankatu, location search is not finding anything since you haven't specified the area where you search. So, you get replies from the free text search. In free text, you have an object with this name which is a road. All buildings in that road are not a part of the database, unless they enter it as POI. To get an address, just add an area. So, the searches

Tukholmankatu 3, Helsinki

or even Tukholmankatu 3, Suomi would probably give what you want.

I am not sure how to improve this - whether to educate us as users or try to fix it in the library or server.
 

The Following 7 Users Say Thank You to rinigus For This Useful Post: