Opened 8 years ago

Closed 6 years ago

Last modified 6 years ago

#3349 closed enhancement (fixed)

Nominatim search result box for boundary=administrative relations do not propse to show boundary relation

Reported by: PierZen Owned by: rails-dev@…
Priority: trivial Milestone:
Component: website Version:
Keywords: boundaries Cc:

Description

Search results for boundary=administrative relations shows a point instead of the boundary contours (boundary relation).

For example, a search for Département de l'Artibonite, Haïti returns the following result in the Nominatim Result Box, OpenStreetMap Nominatim section :

Same within Geoname section -Département de l'Artibonite, Haiti

In these two sections of the Nominatim Search Result Box, It would be more signifiant to show the boundaries on the map proposing url with the option relation=.

For example, it would show for -Département de l'Artibonite, Haiti

When people are searching places in an area, tracing these boundaries would be very helpfull.

Change History (9)

comment:1 Changed 8 years ago by PierZen

Precision : These Nominatim search are made through http://www.openstreetmap.org/

comment:2 Changed 7 years ago by Tom Hughes

Owner: changed from openstreetmap@… to geocoding@…

comment:3 Changed 6 years ago by Sarah Hoffmann

Component: nominatimwebsite
Owner: changed from geocoding@… to rails-dev@…
Priority: majortrivial

comment:4 Changed 6 years ago by Tom Hughes

Resolution: fixed
Status: newclosed

Implemented in b1308a8/rails.

comment:5 Changed 6 years ago by Sarah Hoffmann

Really nice but unfortunately it makes the browser unresponsive when large geometries need to be loaded. Firefox is worst but at some point even Chromium struggles. There is also a problem with synchronization.

Try searching for "England", click on the "England, UK" result and then immediately click on other results in random order. At some point, browser freezes. Firefox (v17) gives up after a while with "script is unresponsive". Chromium recovers but the map jumps back to England, UK. i.e. loading an outdated search result.

comment:6 Changed 6 years ago by Tom Hughes

I wonder if this is an issue with parsing the data? or with leaflet rendering it?

Presumably this is already an issue for anybody that visits the browse page for those relations as they use exactly the same technology to display the object.

comment:7 Changed 6 years ago by Tom Hughes

So I did some tests with the "England" relation on my machine, with Firefox 20 and it takes about 10s to download it, parsing the XML is basically instantaneous and then it takes 3s to display it.

Obviously slower machines and/or browsers may take considerably more time than this...

It's hard to avoid the download time, but that shouldn't block the browser anyway. I can install a data size limit to stop large responses being parsed and rendered - the question is what value we should set it at...

comment:8 Changed 6 years ago by Sarah Hoffmann

No chance to get England to load on my netbook with Firefox 21.0. It already chokes on the boundary of the canton of Zurich. Oddly enough, it loads ok on the browse page and with the given link. It just is slow to load. If I understand the code right, then the geometries aren't cached on the client side. That might help a bit in the case were somebody jumps rapidly between search results.

Just for the record, there is also the possibility to get the geometries from Nominatim. There is already some code in place that simplifies geometries so that they become managable. It's currently only used on the html search interface on nominatim's home page but there is no reason not to make it public.

Having played a bit more with it, the serialisation issue is the more pressing one: search for England, click on 'England,UK', click on something else, wait and see the map jump back to England. On WMT I've solved this with a serial counter, see here but I'm sure the JS gurus here know of a better solution.

comment:9 Changed 6 years ago by Tom Hughes

Oh that's easily solved - 899dab0/rails makes sure any already running load is cancelled before a new one is started.

Note: See TracTickets for help on using tickets.