3.0.1
URLs according to the standard cannot contain spaces. URL encoded spaces are sometimes used.
Unsafe:
Characters can be unsafe for a number of reasons. The space
character is unsafe because significant spaces may disappear and
insignificant spaces may be introduced when URLs are transcribed or
typeset or subjected to the treatment of word-processing programs.
The characters “<” and “>” are unsafe because they are used as the
delimiters around URLs in free text; the quote mark (“”") is used to
delimit URLs in some systems. The character “#” is unsafe and should
always be encoded because it is used in World Wide Web and in other
systems to delimit a URL from a fragment/anchor identifier that might
follow it. The character “%” is unsafe because it is used for
encodings of other characters. Other characters are unsafe because
gateways and other transport agents are known to sometimes modify
such characters. These characters are “{”, “}”, “|”, "", “^”, “~”,
“[”, “]”, and “`”.All unsafe characters must always be encoded within a URL. For
example, the character “#” must be encoded within URLs even in
systems that do not normally deal with fragment or anchor
identifiers, so that if the URL is copied into another system that
does use them, it will not be necessary to change the URL encoding.
If I encode the URL I still get an error. I mentioned that already.
Gives error:
Conversion = ‘2’
As you can’t open the url directly in the browser, there is something else missing here.
{"error":{"code":400,"message":"Cannot perform query. Invalid query parameters.","details":["'Invalid field: LK RHEIN-PFALZ-KREIS' parameter is invalid"]}}
Use the objectID instead to construct the your query. That will avoid issues with spaces.
If that means it’s choking on the %20, it might be that needs double encoding %%20
This is OH sub version dependent.
Where exactly are you putting this url, in a Thing baseUrl box?
I can open it:
{“objectIdFieldName”:“OBJECTID”,“uniqueIdField”:{“name”:“OBJECTID”,“isSystemMaintained”:true},“globalIdFieldName”:"",“geometryType”:“esriGeometryPolygon”,“spatialReference”:{“wkid”:25832,“latestWkid”:25832},“fields”:[{“name”:“cases7_per_100k”,“type”:“esriFieldTypeDouble”,“alias”:“Fälle letzte 7 Tage/100.000 EW”,“sqlType”:“sqlTypeOther”,“domain”:null,“defaultValue”:null}],“features”:[{“attributes”:{“cases7_per_100k”:93.7849672399408}}]}
Also in postman it is working
With OBJECTID it works. However I think the other URL (encoded) should also work
yes, in the baseUrl parameter of a http thing. I got it working now by changing the query so that it does not contain any space anymore. I’ll try the double encoding later
Don’t try random stuff. If you have OH 3.0 you need it, if OH 3.01 or above you don’t need any encoding.
I have 3.0.1
Sorry, my typo, 3.1 or above. You can read about this in that linked post.
Glad you found a solution with the ObjectID.
It does, but only with the correct encoding - you forgot to encode the quotation marks around your county. This should work:
https://services7.arcgis.com/mOBPykOjAyBO2ZKk/arcgis/rest/services/RKI_Landkreisdaten/FeatureServer/0/query?where=county%20%3D%20%27LK%20RHEIN-PFALZ-KREIS%27&outFields=cases7_per_100k&returnGeometry=false&outSR=&f=json
It might be possible, that your browser and postman can enoced this automatically, besides that I’ve no idea why it worked for you.
Oh, and don’t forget the advice that @rossko57 gave you regarding the used version and the double encoding thats eventually needed.
The problem with version 3.0 and the (necessary) % encoding -
It’s catch-22 - for a valid url you must encode spaces as %20 but the binding misinterprets %, and so you need double %%
The spaces should be escaped automatically. So entering spaces should be ok. If not, it‘s a bug.
Yes, you fixed the bug but OP is running an old version.
If having a space violates the standard, accepting it & encoding is a bug IMO.
But when it’s encoded its perfectly acceptable under the standard. It’s not a workaround, it’s just how it works.
But you indicated the binding misinterprets % preventing encoding. (%20 is the space character)
Yes, it was a bug and now it’s been fixed. This is why it depends on the version in use.
2 Likes