Can't set lonlat using setlonlat, setobjectproperty, or editsettings

Hi there,

I have answered you in the original ticket that you need to omit the "/api" in the last URL, instead of:

Use the following:

Best regards.

Thanks Dariusz for clarifying that. However, I've now tried editsettings without the "/api" and unfortunately it still doesn't work for me. After I make the call, it redirects me to https://prtgserver/device.htm?id=9445&tabid=1 but only the location name changes, not the lonlat :(

Hi Alex,

The redirect is correct, as this is the backend API of PRTG.
Have you used the exact same URL as you have written above? If so, then I am afraid that the location "TestDevice" might not work.

Additionally, make sure that it is really longitude and then latitude, not the other way around.

Best regards.

As an experiment, I manually put in my current location (https://www.gps-latitude-longitude.com/gps-coordinates-of-hobart) using the web interface and discovered that to successfully geolocate it, I had to put it as "latitude,longitude" not "longitude,latitude" as shown in the API:

Now all 3 API calls can change the map on the Settings page but none of them put the coordinates in:

https://prtgserver/editsettings?id=9445&location_=Head+Office&username=admin&passhash=1234567890&lonlat_=147.3238148,-42.8819032

https://prtgserver/api/setobjectproperty.htm?id=9445&name=lonlat&username=admin&passhash=1234567890&value=147.3238148,-42.8819032

https://prtgserver/api/setlonlat.htm?id=9445&location=Head+Office&username=admin&passhash=1234567890&lonlat=147.3238148,-42.8819032

https://en.wikipedia.org/wiki/ISO_6709 states that "latitude,longitude" is the international standard. Likewise, this is what the World Geodetic System 1984 uses https://epsg.io/4326, and https://www.opengeospatial.org/standards/wms and Google Maps.

May I highly recommend please adding an ISO compliant API call and updating the API documentation:

Hopefully that will also fix the bug of the latitude and longitude not showing on the Settings page :)

Hi there,

I actually found my mistake with the "/editsettings" call. I missed the underscore after "lonlat":

The above call will set the location to New York with the coordinates of New York.
As the parameter "lonlat" indicates, the longitude comes before the latitude. There are currently no plans to change this within the current API Version. Maybe we will address this in the future when the API is getting extended or rewritten. That means for now the coordinates need to be switched (if you use ISO compliant coordinates in the first place).

Best regards.

I'm disappointed that they aren't willing to add one call to make the API ISO compliant. If they don't do that, how are we going to fix the bug with the latitude and longitude not showing up in the location field on the Settings page after an API call? editsettings, setobjectproperty, and setlonlat all change what the map shows but none add the text in the location.

Hi Alex,

I understand that this might upset you, but there are currently too less users that actually do this via the API. Please note that this would require not just an rewrite of how the API works but also how the Core handles and submits the coordinates to the map services.

Have you tried the above API-Call? I verified that this works without any issue, it also fills the location field. Just make sure that the coordinates are in the correct order.

Best regards.

If all you actually want to do set the address of things (without specifying coordinates) this is a whole lot easier to do with PrtgAPI

C:\> Get-Device -Id 1001 | Set-ObjectProperty Location "new york, new york, usa"

This will then have PRTG look up whatever the latitude and longitude are supposed to be for you, then set the address in the UI using the nicely formatted text returned by the map provider.

C:\> Get-Device -Id 1001 | Get-ObjectProperty Location
New York, NY, United States

The final API request that is executed by Set-ObjectProperty is as follows

http://prtg.example.com/editsettings?id=1001&location_=New+York%2C+NY%2C+United+States&lonlat_=-74.00714%2C40.71455&locationgr
oup=0&username=prtgadmin&passhash=12345678

which is basically the same thing Dariusz posted above, however also disables location inheritance ("locationgroup=0", which could be important)

Specifying actual coordinates instead of addresses isn't currently supported by PrtgAPI yet, however even you rolled your own solution, it doesn't really matter how PRTG constructs its request; you can simply construct your own function that takes the parameters in the correct format reformats them appropriately for use with PRTG

Dariusz we've got about a 1000 devices so it's not feasible to manually have to enter data for each. I have no trouble getting the API to change the underlying field, it just doesn't update the Settings page properly.

Thanks LordMilko, I tried "locationgroup=0" but that didn't have an effect for me as the location inheritance is already disabled on the object.

Anyway, as a workaround, I ended up forcing it to write the extra information into the field so my Python code now looks like this:

encoded_args = urlencode({'id': device_id,
                          'location': f'{location_name}\n{lat},{lon}',  # Workaround
                          'lonlat': f'{lon},{lat}'})

http.request('GET', f'{prtg_api}setlonlat.htm?{encoded_args}{authentication}')

Your 'location' and 'lonlat' properties do not end in underscores. Generally speaking all properties passed to /editsettings must end in underscores, with the exception of inheritance related properties (such as locationgroup)

Unless all 1000 objects already have location inheritance disabled, and you don't anticipate interacting with any new objects that don't have this inheritance disabled in the future, I would generally recommend always including locationgroup=0, to ensure you never have to worry about the state of this setting