Skip to content
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

Closed
tmcw opened this issue Sep 4, 2012 · 6 comments
Closed

Write and use jsonp api for nominatim for the rails port #80

tmcw opened this issue Sep 4, 2012 · 6 comments

Comments

@tmcw
Copy link
Contributor

tmcw commented Sep 4, 2012

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.

@tomhughes
Copy link
Member

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.

@systemed
Copy link
Contributor

systemed commented Sep 4, 2012

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.

@tomhughes
Copy link
Member

Geonames is the main one sure, but there are also several postcode search engines as well.

@apmon
Copy link
Member

apmon commented Sep 4, 2012

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?

@tomhughes
Copy link
Member

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.

@lonvia
Copy link
Contributor

lonvia commented Sep 5, 2012

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants