You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The parseParams function is splitting a well-known text geometry on the commas separating the coordinates. This use case is occurring when using the getQueryString. I think the issue is the parseParams passes the prop arrayFormat as "comma," to parse from query-string, instead of leaving the default which is none.
The text was updated successfully, but these errors were encountered:
Good catch! It's entirely possible we will have arguments in which we want commas to be handled differently, but I think we want there to be a "sane default" behavior. I don't know if the underlying query-string library has internal tools for treating parameters separately.
It looks like you can override the comma-parsing behavior in parseParams by passing your own arrayFormat argument, but this config option isn't passed through to the getHashString and setHashString functions. We should pass through the opts argument if we can.
Even this doesn't help with our problem though, because that solution breaks if we want to handle WKTs and arrays (e.g. nest=... in Sparrow) in the same parameter array. Perhaps a solution would be to urlencode the commas in the WKT somehow?
The parseParams function is splitting a well-known text geometry on the commas separating the coordinates. This use case is occurring when using the
getQueryString
. I think the issue is theparseParams
passes the proparrayFormat
as "comma," toparse
from query-string, instead of leaving the default which is none.The text was updated successfully, but these errors were encountered: