API REST Services for Identify features / mapExtent, imageDisplay, tolerance parameters

Wendelin Steiner

unread,

Jul 14, 2022, 11:50:29 AM7/14/22

to GeoAdminCh API

Hi everyone,

I'm using the API REST service from geo.admin for a hobby project and I'm struggling a lot with the "Identify Features" to discover features at a specific location.

https://api3.geo.admin.ch/services/sdiservices.html#identify-features

In short I'm using the following

When clicking on the map, I would like to look up with the "Identify Features" what the user selected. Seems to be a very simple use case, but damn how I struggle with the implementation. I'm using axios for the query and added the code in the appendix if someone wants to have a look on it. (geo-admin.js.jpg - remove the jpg extension, as I was not able to upload a .js file directly)

I have difficulties to understand the query parameters, especially mapExtent, imageDisplay and tolerance.
Do you have a good source, where I can read more about it?

My understanding after further studying the API and the the request that are sent from the https://map.geo.admin.ch/ website is as followed:

tolerance
I couldn't get a better understanding of how tolerance works, but I used a fix value of 10, as it is used in map.geo.admin.ch map and I was happy with the selected features. Maybe you can further elaborate on what is meant by tolerance.
displayImage (height, width, dpi)
height: height of the DOM element in pixel
width: width of the DOM element in pixel
dpi: unfortunately no idea how to calculate it, but I used 96 as default value as it is also used on map.geo.admin.ch. Do you have a better suggestion?
mapExtent (minx, miny, maxx, maxy)
Corresponds to the borders of the visible map in the DOM element and corresponds to the
(border left -> min. longitude
border bottom -> min. latitude
border right -> max. longitude
border top -> max. latitude
As I'm using 3857 spatial reference, the values are in degrees.

So the payload would look like this:
Screenshot 2022-07-14 at 18.24.52.png

Unfortunately I get 0 results back. Do you have an idea, what I did wrong? Or how I misunderstood the API?

Any help is appreciated. Btw. I'm a beginner with geo data and might have done some beginner mistakes.

geo-admin.js.jpg

Pascal Barth

unread,

Jul 15, 2022, 3:06:50 AM7/15/22

to geoadm...@googlegroups.com

Hello!

Yeah the backend has quite the number of mandatory params...

You can find a bit more information on each param here : https://api3.geo.admin.ch/services/sdiservices.html#identify-features

If you want a good example with axios on how to handle the API, you can inspire yourself with how we deal with it in the new viewer : https://github.com/geoadmin/web-mapviewer/blob/748e2886183b6fdd1f1de861da04154303aba14d/src/api/features.api.js#L288-L356

Or you could simply use this file in your project, it shouldn't be too hard to gather all its dependencies (it's meant not to use our UI or state framework)

When dealing with EPSG:3857 values, you have to also check if you are not writing them in an unexpected order for the service. As there's not a standard if coordinates should be described as Lat/Lon or Lon/Lat, it's always a good idea when you get nothing to check the other way around.

There also might be something to do with the layer param, I'm not sure you can just ask for an identify on our 800+ layers in one go, you might need to define on which layer(s) you want the identification of feature to happen.

For you other questions :

- Tolerance : it's the number of pixel around your coordinates, the endpoint is tailor made for our frontend, so the frontend is sending it's DPI and screen size, a tolerance, and the backend does the math.

- imageDisplay : as stated above, that's required so that the backend can calculate the tolerance in real coordinates

Small sidenote: if you want something more OpenSource for the mapping framework, there's now an alternative to Mapbox in Maplibre, they are close to feature parity with Mapbox v1 and are pushing some new features that were requested from long before on Mapbox (but didn't fit well with a licensed approached)

Hope it helps.

Pascal

--
You received this message because you are subscribed to the Google Groups "GeoAdminCh API" group.
To unsubscribe from this group and stop receiving emails from it, send an email to geoadmin-api...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/geoadmin-api/732174c6-1631-4cc7-aa1e-a1253b85d6a8n%40googlegroups.com.

Loïc Gasser

unread,

Jul 15, 2022, 8:53:56 AM7/15/22

to geoadm...@googlegroups.com

Hey 👋

I noticed you specified sr 3857 when your cooridnates look like 4326.

Hope this helps!

To view this discussion on the web visit https://groups.google.com/d/msgid/geoadmin-api/CAL%2BBOM3bU7JHZP8jO_uo4c_4F7mJaEms_1WAN8weyQ%3DUaMt_ow%40mail.gmail.com.

Wendelin Steiner

unread,

Jul 16, 2022, 2:58:17 AM7/16/22

to GeoAdminCh API

Hello Pascal, hello Loïc,

Thank you Pascal for showing me the example with the web-mapviewer. This showed me that I was on the right track.

I especially like the layer implementation classes and might borrow some of the code at a later refactoring :).

Thank you Loïc for your highlighting the issue with sr 3857 and 4326. As I'm new to this geodata handling I still get confused from time to time.

From my understanding:

Mapbox renders the map in 3857, however when clicking on the map it return the coordinates in 4326. Therefore I have changed my request to the geoadmin backend to sr 4326.

Seems like now I'm getting results back (however there is still one issue left).

and the result:

The issue I currently have is the following:

In order to get results I had to set the tolerance to 1000 which according to Pascal is the number of pixel around the coordinates.

1000 seems like a big tolerance value, compared to the 10 used in the web-mapviewer.

Any idea why I need such a big tolerance as parameter in order to work?

Best regards and thanks for your help,

Wendelin

Loïc Gasser

unread,

Jul 16, 2022, 1:43:15 PM7/16/22

to geoadm...@googlegroups.com

Hi again!

mapExtent coordinates order seems incorrect.

It shou be:

minx, miny, maxx, maxy

To view this discussion on the web visit https://groups.google.com/d/msgid/geoadmin-api/0f7df0a1-b4e9-4bb2-91cd-670b8cd6f2e2n%40googlegroups.com.

Screenshot 2022-07-16 at 09.46.52.png

Screenshot 2022-07-16 at 09.47.00.png

Wendelin Steiner

unread,

Jul 22, 2022, 4:53:25 AM7/22/22

to GeoAdminCh API

Hi Loïc,

Thanks for your answer. I adjusted my code and unfortunately I seems not working correctly.

Currently my payload looks as followed:

However now I don't receive any results back.

Keep in mind, that the tolerance is still high with 1000 and the geometry point lies within the map extent.

xmin: 7.4408 < xpoint: 7.4612 < xmax: 7.4784

ymin: 46.9300 < ypoint: 46.9519 < ymin: 49.9661

Any idea, why I don't get any results back?

And I'm even more curious to why I received results with the wrong xmin, xmax, ymin, ymax order in the first place (see my previous comment)...

Thanks for your help in advance.

Best regards,

Wendelin Steiner

Loïc Gasser

unread,

Jul 22, 2022, 3:16:11 PM7/22/22

to geoadm...@googlegroups.com

Seems like a bug then 😀 with 4326 in the identify service, my best advise is to use 3857 instead. (This seems to work since geoadmin uses it!)

For the conversion:

https://docs.mapbox.com/mapbox-gl-js/api/geography/#mercatorcoordinate

const coord = mapboxgl.MercatorCoordinate.fromLngLat({lng: 0, lat: 0}, 0);

console.log(coord); // MercatorCoordinate(0.5, 0.5, 0)

Altitude at 0 should be fine for your use case.

To view this discussion on the web visit https://groups.google.com/d/msgid/geoadmin-api/61be0317-90a8-400f-b37c-29f5352a07bcn%40googlegroups.com.

payload.JPG

results.JPG

Wendelin Steiner

unread,

Jul 25, 2022, 3:14:07 PM7/25/22

to GeoAdminCh API

Hi Loïc,

Do you know where I can report this bug?

Because it seems to add more complexity to the code and it seems to still not work out...

Lets take the following example with the train station Bern:

Train station Bern

sr4326--> lon: 46.948959658148794 , lat: 7.439968988600931

this converts to the following

x: 0.6304137768281911

y: 0.47927509508598665

However it should transform to the following (according to epsg.io)

sr3857 --> x: 828213.55, y: 5933746.98

I see that Mapbox wrote the following:

MercatorCoordinate uses the web mercator projection (EPSG:3857) with slightly different units:

the size of 1 unit is the width of the projected world instead of the "mercator meter"
the origin of the coordinate space is at the north-west corner instead of the middle.

Any idea how I can transform the unit to meters?

I guess I need to use another library for the projection...

Best regards and thank you,

Wendelin

Maurizio Manca

unread,

Jan 26, 2023, 5:38:46 PM1/26/23

to GeoAdminCh API

I guess that after many months you must have figured it out but your lat and lon parameters were inverted in the call to the conversion function.
46 is more a latitude in Switzerland than a longitude :)

By the way I'm running into the same issue and not getting any result back when using a layer with just some scattered points like "ch.swisstopo.amtliches-gebaeudeadressverzeichnis"

I don't have a clue on which tolerance, mapExtent and imageDisplay to use.

Does anyone know if it's possible to configure map.geo.admin.ch to use 4326 coordinates in the calls in order to compare their calls to identify to mine when clicking on the same point ?

Regards

Marc Monnerat

unread,

Jan 27, 2023, 7:28:54 AM1/27/23

to geoadm...@googlegroups.com

Hello,

The only supported SRS is LV95 and the legacy LV03. Services may work to some extent with 'EPSG:3857' and 'EPSG:4326', but especially the latter was never really used and tested. The application (soon to be replaced) https://test.map.geo.admin.ch is using Webmercator internally.

Some example requests with the 'identify' and 'features' services. As already stated, the 'EPSG:4326' is wrong (but it's not supported)

Regards,

Marc

To view this discussion on the web visit https://groups.google.com/d/msgid/geoadmin-api/ccbfabb3-b7ed-43fc-957b-2bac378d421fn%40googlegroups.com.

--

Всё идёт по плану

Reply all

Reply to author

Forward