-
Notifications
You must be signed in to change notification settings - Fork 908
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Write and use jsonp api for nominatim for the rails port #80
Comments
The only issue with that is that the search system is built as a multi-backend infrastructure with code being shared among the different search engines as much as possible. So moving one to client side means breaking that shared code approach. That said, it may well be that we can drop the other search engines now - they were important in the early days but our data is probably rich enough to stand alone now. Either that or we can move the whole thing to the client. |
I'd support removing the other engines (principally Geonames). 95% of the time, Nominatim returns the right result; for the remaining 5%, being able to get there via Geonames is actually a disincentive to add the place to OSM. |
Geonames is the main one sure, but there are also several postcode search engines as well. |
If there is only one search backend, would you be OK with the search going directly from the client to nominatim and not through the rails_port? I am wondering as (if I remember correctly) one of your main comments / complaints about the original routing integration into osm.org was that it called the routing engine backend directly from the client javascript code. I never quite understood why it was preferable to route everything through the rails backend, but because of that Frederik rewrote the routing integration to redirect everything through the rails_port code. Did Frederik and I misunderstand you back then? Or has your opinion on this changed? Or is the routing code a different situation that doesn't compare to this one? |
I may be remembering wrongly, but I suspect it was the HTML code for the interface that I wanted as a proper part of the rails code rather than as a static HTML file. I don't think I objected to having the client get the actual route directly, but I might be wrong. |
Speaking for the Nominatim part only: Main issue with that is the descriptive term in front of the search result. Nominatim only delivers a class/type pair (i.e. the key and value of the main tag) which is translated and localized into the descriptive term by rails. So, in order to get this on the client side, you'd have to translate half the locale ymls to javascript. There is this vague idea in my head to move the entire logic about descriptions into Nominatim but it needs some investigating if that is feasible (and wanted, for that matter). May I suggest you hold off rewriting the rails code until I've had time to look into that? |
Right now the rails port dispatches requests to nominatim ( https://github.com/openstreetmap/openstreetmap-website/blob/master/app/helpers/geocoder_helper.rb#L24 ) and parses the XML, and then formats. This could be more efficient if the browser hit nominatim directly and got JSONp that could be easily formatted into page content.
The text was updated successfully, but these errors were encountered: