search

WNRI / route.is

Source code for the hiking information service route.is.
route.is
GNU General Public License v3.0
1 stars 2 forks source link

Named and direct URLs #13

Open dittaeva opened 12 years ago

dittaeva commented 12 years ago

The user should be able to go directly to a relation with route.is/[relation ID], and directly to a named route with route.is/California%20Coastal%20Trail, or directly to a view of a named area with route.is/in/California. All other URLs with text should be redirected to search, f.ex.

See also lonvia/waymarked-trails-site#58 which is the same issue, but for Waymarked Trails.

esisa commented 11 years ago

Today you can go to route.is/relation/1114901 and it will take you directly to this relation. Do you want to change that to just route.is/1114901 as well?

esisa commented 11 years ago

Apparently going directly to a route name is also supported now: route.is/nb/route/Turvei A3

dittaeva commented 11 years ago

I want to skip the "[language code]/route/" part, and be able to go to area with route.is/in/, and redirect to search when either doesn't match existing routes/areas. There's a conflict with the language codes here, not sure what to do with that, there might be other conflicts as well.

So, I'd like "route.is/Turvei A3" to tak me directly to the route, "route.is/Turvaei A3" to take me to search, and "route.is/in/Sogndal" to take me to map centered on Sogndal municipality (area) with the route list open, and "route.is/in/Sogndæl to take me to search. The route.is/in feature probably needs to only look at areas with administrative codes of some sort.

esisa commented 11 years ago

So for route.is/in/California you just want to got to the first result in Nominatim?

And a URL like this route.is/Jotunheimen should go to the search panel?

dittaeva commented 11 years ago

I guess the language codes are always shorter than relation numbers (and only with numbers, so there shouldn't be a conflict there. Route names could probably conflict with language codes, but those conflicts would be few, and one could differentiate between language code and route name with a "/" on language names.

esisa commented 11 years ago

Ok, you answered most of my questions while posting them :-)

But you want to remove the language code entirely from the URL?

dittaeva commented 11 years ago

So for route.is/in/California you just want to got to the first result in Nominatim?

I suppose yes, and I suppose the state is on top because it has "Admin Level: 4".

And a URL like this route.is/Jotunheimen should go to the search panel?

If there is no route by that name, yes.

dittaeva commented 11 years ago

But you want to remove the language code entirely from the URL?

I suppose so, at least from the URL that is used/displayed. Gotta go now.

esisa commented 11 years ago

Ok, then I need to check how to do the translations without the language code.

dittaeva commented 11 years ago

I thought it was independent of the url (detected) already.

esisa commented 11 years ago

Ok, I will check it out.

esisa commented 11 years ago

I have commited some code which makes is possible to do:

route.is/Turvei A3 -> opens the relation route.is/Turvaaai A3 -> opens the search panel route.is/1629177 -> opens the relation

The code still adds the language code. I'll try to remove that. And I need to add the route.is/in URL's.

esisa commented 11 years ago

Now it is also possible to open an area by using the URL: route.is/in/Jotunheimen -> opens the map showing Jotunheimen area, and opens the routes panel

It takes only the first result matching one of the types defined here: https://github.com/Kresendo/waymarked-trails-site/blob/master/django/src/routemap/apps/search/views.py#L124

Still haven't removed the language code yet. I will leave this issue for comments now, before I continue.

dittaeva commented 11 years ago

This seems to work very well indeed. I am still not sure about the language codes, so as long as URLs without them also work I think we can leave them in. One feature that I do miss is for the header text of the route list to include the name of the area we are seeing.

So instead of "Routes in area" it would say "Routes in Jotunheimen". This might as well be a feature that is always used for the route list so that whichever area you are looking at it would be in the header. Does nominatim support such an "inverted" search?

dittaeva commented 11 years ago

@lonvia this is now live on http://test.route.is , would you like a pull request for Waymarked Trails?

lonvia commented 11 years ago

I'd certainly love to see issue 58 solved and the 'in/' link is really nice, too. I'd prefer keeping the route/relation links, though.

If you don't like the language prefixes, you can switch Django to language support via cookies. I think it is sufficient to replace the i18n_patterns with normal patterns. Check out the Django docs around this section.

esisa commented 11 years ago

One feature that I do miss is for the header text of the route list to include the name of the area we are seeing.

Ok, that is fixable.

So instead of "Routes in area" it would say "Routes in Jotunheimen". This might as well be a feature that is always used for the route list so that whichever area you are looking at it would be in the header. Does nominatim support such an "inverted" search?

You can do reverse geocoding, but I think it only gives you administrative areas.

dittaeva commented 11 years ago

Ok, then let's do both. When area has been specified with the URL (route.is/in/Jotunheimen) we use the area name from the URL, when just bringing up list of routes for an area we use reverse geocoding. If the name is too long for the list box it should be cut off with "…".

dittaeva commented 11 years ago

I'd prefer keeping the route/relation links, though.

Ok, we'll enable them too then.

If you don't like the language prefixes, you can switch Django to language support via cookies. I think it is sufficient to replace the i18n_patterns with normal patterns. Check out the Django docs around this section.

Let's do that @esisa

esisa commented 11 years ago

It does not seems like Nominatim return an area name that we can actually use so I will skip that feature.

Example Eidsbugarden, Jotunheimen. http://nominatim.openstreetmap.org/reverse?format=xml&lat=61.37465&lon=8.29266&zoom=18&addressdetails=1

esisa commented 11 years ago

If you don't like the language prefixes, you can switch Django to language support via cookies. I think it is sufficient to replace the i18n_patterns with normal patterns. Check out the Django docs around this section.

I cannot get this to work. The language support break if I replace i18n_patterns with normal patterns. I tried lots of different solutions, but none have worked so far.

dittaeva commented 11 years ago

Then lets just keep them in for now.

fredag 14. juni 2013 skrev Espen Oldeman Lund:

If you don't like the language prefixes, you can switch Django to language support via cookies. I think it is sufficient to replace the i18n_patterns with normal patterns. Check out the Django docs around this section.

I cannot get this to work. The language support break if I replace i18n_patterns with normal patterns. I tried lots of different solutions, but none have worked so far.

— Reply to this email directly or view it on GitHubhttps://github.com/WNRI/route.is/issues/13#issuecomment-19456228 .

esisa commented 11 years ago

Then lets just keep them in for now

OK.