-
Notifications
You must be signed in to change notification settings - Fork 8
Distance for reverse geocoding requests #887
Comments
Thank you for your feature request. It is unlikely that this feature will be implemented any time soon. Therefore, you will have to calculate the distance between the query point and the object on the client to verify that the object is close enough for your purposes. An approximate distance can be easily calculated from the bounding box. Otherwise you probably want to use a third party library for the calculations. If this feature is implemented in the future, it would probably be done by adding reverse geocoding parameters to the regular query endpoints, such as https://dawa.aws.dk/vejstykker , where a circle parameter is already available. It is unlikely that we will provide the distance from the query point in responses, as this would require a new response structure and therefore a significantly higher implementation effort. |
@andershessellund Thanks for the prompt answer. I understand that I can calculate the distance myself. However, that is not a trivial task to do it properly (e.g. to calculate distance between a point and a MultiLineString on a globe) and I'm not able to find a library for my environment which does that properly. Besides, you already have that st_distance call in the server. So, i thought it would be much easier to do it via this "cirkel" param. This would save me and other people some time. Plus, less calculations means less greenhouse emission :). In any case, it's up to you to make a final decision here. |
@dmytro-gokun Will the following request meet your needs? |
@finnjordal Absolutely. If it works and returns the correct road information that is exactly what I need. |
@dmytro-gokun It works :) |
@finnjordal Does it? When I hit this link:
it returns:
If i increase radius to 1000 - nothing, 10000 - still nothing. Only something insane, like 1000 km:
returns plenty of roads far away. Not very useful. If you looks at this point on Google Maps: https://www.google.com/maps/place/58%C2%B040'59.7%22N+15%C2%B035'06.5%22E/@58.6832384,15.5829585,17z/data=!3m1!4b1!4m5!3m4!1s0x0:0x0!8m2!3d58.6832384!4d15.5851472 you can see that it is in the middle of country and has lot of of roads around. I could be doing it wrong though. Any help is appreciated. |
@dmytro-gokun DAWA only covers Denmark. Coordinates you use are located in Sweden. |
@finnjordal Oh, you are right. The only reason i've tried those coordinates was because they were in your sample :D. But it works great, indeed. Thanks a lot! Do you perhaps know if result set is ordered by increasing distance from the original point or not? |
@dmytro-gokun The sort order is increasing (kommunekode, vejkode) |
@finnjordal You mean its sorted alphabetically be (kommunekode, vejkode) and not by distance? |
@dmytro-gokun yes |
@finnjordal Okay. I guess it does not make big difference for small radius... Still, to me it would make much more sense if it were sorted by distance. In that case I'd be able to take the first one and be sure it is what I need (the closest road). Do you perhaps know what is the sort order when using "cirkel" parameter with "adgangsadresser" endpoint? |
@dmytro-gokun For addresses ("adgangsadresser"), there is no sort order |
@finnjordal Do you think there is any chance that might be fixed? Again, when one is looking for a closest address (or road), it makes sense to sort accordingly... |
Hi,
thanks a lot for a great service. I have a feature suggestion which in my opinion would be beneficial for many and is relatively easily to implement.
The problem today is that reverse geocoding requests (for both addresses and roads) simply return the closest object, even if it is hundreds kilometers away. That does not make much sense for practical use.
For example, this request: https://dawa.aws.dk/vejstykker/reverse?x=15.5851471984198&y=58.6832383751223&format=geojson&struktur=nestet
gets back a road with
while in fact i'm interested in a road which is no more 100 meters away from my point.
I see two ways to implement this:
Option (1) seems to be easier to implement while preserving backward compatibility.
Is there any chance this may be implemented any time soon?
Thanks in advance.
The text was updated successfully, but these errors were encountered: