Are there any binary releases available? This would reduce the compile time quite a bit, which is nice for building hosted online environments more quickly.

This would be really helpful as users would not need to write their own solutions to what appears to be a standard best practice for RESTful APIs, see https://www.moesif.com/blog/technical/api-design/REST-API-Design-Filtering-Sorting-and-Pagination/.

https://xyz.api.here.com/hub/static/swagger/#/Read%20Features/getFeaturesBySpatial

There is a need to store encrypted secrets in either space definitions or token metadata:

There already are several connectors that need credentials to access external resources. These credentials should not be stored as clear text with the connector's configuration within a space in order to prevent unauthorized access.

Since this functionality is already needed in several connectors today, we think it should be provided centrally as part of the XYZ infrastructure, especially since the number of affected connectors will likely rise in the future.

One possible way would be to implement this functionality inside XYZ hub so the credentials are decrypted when calling connectors that need them. The need for encryption and decryption might be signified by e.g. a prefix to field names within the connector configuration. This would be the most convenient way for connector developers. However, it has the potential to introduce significant overhead within XYZ hub which is not desirable. Additionally, great care would need to be taken in order to prevent accidental leaking of decrypted secrets during the (external) call to the connectors, e.g. by logging the request to the connector prior to sending it.

To us it is clear that the decryption process should take place inside the individual connectors. However, we think this should happen in a uniform way and would like to spare connector developers from having to implement decryption routines from scratch for every new connector.
First, getting it done right will prevent errors in the en- and decryption routines to leak credentials to the outside and second it will prevent developers writing the same boiler plate code over and over.

Therefore, we suggest to expand the xyz-connector libraries in order to add support for de- and encrypting secrets using asymmetric (public/private key) encryption. By utilizing a service like Amazon's KMS we can ensure that connector code does not get direct knowledge of the private key, thus enabling us to use a single, strong public/private key pair per environment for all connectors deployed there in order to keep things simple. Despite that, it would still be possible to use individual public/private key pairs for certain connectors if that requirement should arise.

Preliminary technical proposal for further discussion:

• We need to configure a private/public key pair. The public key is used for encrypting the secrets either by the users or the connector. The private key should only be accessible by the connector to decrypt the secrets.
• The public key needs to be accessible - either in the documentation of XYZ Hub or there is an REST/HTTP call to get it.
• Add a new helper class to XYZ connectors lib that needs to know where to find the public/private key pair. We would suggest to use AWS KMS to store them. The helper class will have methods for en- and decryption the secrets. If no public/private key pair is configured, the values will be returned as is.
• In ListenerConnector.java and ProcessorConnector.java we will check if the connector params, params or token metadata contain values that are enclosed in a certain pre- and postfix. We would suggest using "<<" and ">>".
• If such values are found, the configured private key is used to decrypt the values and forward it to the custom connector implementation.
• Automatic encryption using format ">>PLAINTEXT<<"
• Automatic decryption using format "<<CYPHERTEXT>>"

In section Getting started, the shell commands should be

git clone https://github.com/heremaps/xyz-hub.git
cd xyz-hub
mvn clean install

Hello, I encountered some problems when using this program. I want to ask:
When there are many concurrent requests, an error of 429 will be reported:
tile-layer.js:37

   Error: es/world/tile/web/12_3291_1673.mvt (429): Too Many Requests {"type":"ErrorResponse","error":"Exception","errorMessage":"Remote function is busy or cannot be invoked.","streamId":"z2XCiecK3A"}...
at checkResponse (response-utils.js:45:1)
at async getArrayBufferOrStringFromData (get-data.js:57:1)
at async parseWithLoader (parse.js:42:1)
at async parse (parse.js:37:1)
at async load (load.js:23:1)
at async Tile2DHeader._loadData (tile-2d-header.js:83:1). 

what should I do?

Please add following api to xyz-hub, so XYZ Studio works with Hub

• project-api
• screenshot-api

This would be really helpful as users would not need to write their own solutions to what appears to be a standard best practice for RESTful APIs, see https://www.moesif.com/blog/technical/api-design/REST-API-Design-Filtering-Sorting-and-Pagination/.

https://xyz.api.here.com/hub/static/swagger/#/Read%20Features/searchForFeatures

This would be really helpful as users would not need to write their own solutions to what appears to be a standard best practice for RESTful APIs, see https://www.moesif.com/blog/technical/api-design/REST-API-Design-Filtering-Sorting-and-Pagination/.

https://xyz.api.here.com/hub/static/swagger/#/Read%20Features/getFeaturesByTile

i was expecting to see the local installation of xyz-hub to have the swagger documentation but not sure if it's available and i can't find its end point or still to be upcoming

This would be really helpful as users would not need to write their own solutions to what appears to be a standard best practice for RESTful APIs, see https://www.moesif.com/blog/technical/api-design/REST-API-Design-Filtering-Sorting-and-Pagination/.

https://xyz.api.here.com/hub/static/swagger/#/Read%20Features/getFeaturesByBBox

hey all!

maybe a long standing typo, but using custom http errors makes creating code stubs from swagger almost impossible. you should change your custom 513/payload too large to standard http 413 Payload Too Large

would also make more sense to have it as as 4xx client and not a 5xx server error

O

This would be really helpful as users would not need to write their own solutions to what appears to be a standard best practice for RESTful APIs, see https://www.moesif.com/blog/technical/api-design/REST-API-Design-Filtering-Sorting-and-Pagination/.

https://xyz.api.here.com/hub/static/swagger/#/Read%20Features/getFeaturesBySpatialPost

I was using the spatial search function here (https://xyz.api.here.com/hub/static/swagger/#/Read%20Features/getFeaturesBySpatial) and noticed I wasn't getting results when I should have. The reason I didn't is because the 'default' text for params included this code:

OrderedMap { "p.myProperty": "someValue", "p.otherProperty": 5 }

Other fields on the form have descriptive text for the field but they do NOT actually get sent to the API. So for example:

Even though you see text in limit, it's not actually passed to the API.

To fix this, we need to remove the text from the textarea so it doesn't get passed when a user doesn't notice that it is "real" text.

Currently, loading GeoJSON content with (standard) GeometryCollections leads https://geojson.tools to report errors s.a. 1 feature(s) added successfully and 1 feature(s) failed to load, without rendering said GeometryCollections.

Although the limitation is documented (GeometryCollection is not supported by HERE XYZ Hub. It is just included here for completeness.), it forces us to resort to other web applications (s.a. https://geojson.io) to get rendering - thus without HERE maps.

Could you therefore please consider supporting GeometryCollections?