View Single Post
Posts: 480 | Thanked: 2,286 times | Joined on Aug 2016 @ Estonia
#10
Originally Posted by otsaloma View Post
I doubt it's unexpected, since I see it all over the place: regular roads, forks, labels wrapping around a U-turn, etc. Couple examples below, center of the screen.

https://postimg.org/gallery/d4dc0wbm/
In general, it looks similar to what I see. However, I haven't spotted upside-down labels as you did yet.


Originally Posted by otsaloma View Post
I understand that it's a very difficult problem to parse and match search queries when people give them in many different formats and sometimes you might have partial matches, e.g. street found, but not the the full address, etc. But I also think that search should work with the same format queries as with online providers. Especially in an app like Poor Maps, which supports several providers and has a common history. No-one is going to read a long manual -- if normal search queries don't work, users will just conlude your software is broken.

Since it's a big problem, I wonder if there's a suitable external library you could use instead of trying to solve the problem on your own? For example, Mapzen has recently released Libpostal -- "a fast, multilingual, international street address parser trained on OpenStreetMap data".

https://mapzen.com/blog/inside-libpostal/
libpostal seems to be an interesting option. It looks that this is a preprocessor for the database query (see https://github.com/openvenues/libpos...not-a-geocoder ). Its an interesting option and certainly has to be tested. However, they do state that use on a mobile is "conceivable" and that its not designed with that in mind. I'll add libpostal to the todo (issues in github) and would take a look on it in future.

In case of Erottaja, Helsinki, libpostal would not help, I think. I'll have to check what is included into the search database as location and what is not. Hopefully, we can fix it.
 

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