Missing paths when upgrading from koop@5.1.1 to @koopjs/koop-core@10.4.15

[bamse16]

When upgrading from koop@5.1.1 to @koopjs/koop-core@10.4.15, some of the endpoints are removed.

This seems to be introduced by @koopjs/output-geoservices@5.0.0 that removes FeatureServer routes that do not include /rest/services.

Some of the services we've set, are used by other clients by including old service url (e.g. /tc-file/:id/FeatureServer).

Any chance to reconsider and introduce the old style in a future @koopjs/output-geoservices upgrade? Without that, there ins't really an upgrade path from koop@5.1.1 to latest @koopjs/koop-core that's not breaking for existing users.

Thank you

---

Debug info:

Using koop@5.1.1

const Koop = require("koop");
const koop = new Koop();
// Hack to fix missing logger in @koopjs/provider-file-geojson
koop.logger = koop.log;
const provider = require("@koopjs/provider-file-geojson");
koop.register(provider, { name: "tc-file", dataDir });

"Geoservices" output routes for the "tc-file" provider   Methods  
-------------------------------------------------------  ---------
/tc-file/:id/FeatureServer                               GET, POST
/tc-file/:id/FeatureServer*                              GET, POST
/tc-file/:id/FeatureServer/:layer                        GET, POST
/tc-file/:id/FeatureServer/:layer/:method                GET, POST
/tc-file/:id/FeatureServer/layers                        GET, POST
/tc-file/:id/MapServer*                                  GET, POST
/tc-file/rest/info                                       GET, POST
/tc-file/rest/services/:id/FeatureServer                 GET, POST
/tc-file/rest/services/:id/FeatureServer*                GET, POST
/tc-file/rest/services/:id/FeatureServer/:layer          GET, POST
/tc-file/rest/services/:id/FeatureServer/:layer/:method  GET, POST
/tc-file/rest/services/:id/FeatureServer/layers          GET, POST
/tc-file/rest/services/:id/MapServer*                    GET, POST
/tc-file/tokens                                          GET, POST
/tc-file/tokens/:method                                  GET, POST

Using @koopjs/koop-core@10.4.15

2024-07-04T01:06:11.560Z info: "GeoServices" routes for the "tc-file" provider:
2024-07-04T01:06:11.561Z info: ROUTE | [GET, POST] | /tc-file/rest/info
2024-07-04T01:06:11.561Z info: ROUTE | [GET, POST] | /tc-file/rest/generateToken
2024-07-04T01:06:11.561Z info: ROUTE | [GET, POST] | /tc-file/rest/services/:id/FeatureServer
2024-07-04T01:06:11.561Z info: ROUTE | [GET, POST] | /tc-file/rest/services/:id/FeatureServer/layers
2024-07-04T01:06:11.561Z info: ROUTE | [GET, POST] | /tc-file/rest/services/:id/FeatureServer/:layer
2024-07-04T01:06:11.561Z info: ROUTE | [GET, POST] | /tc-file/rest/services/:id/FeatureServer/:layer/info
2024-07-04T01:06:11.561Z info: ROUTE | [GET, POST] | /tc-file/rest/services/:id/FeatureServer/:layer/query
2024-07-04T01:06:11.561Z info: ROUTE | [GET, POST] | /tc-file/rest/services/:id/FeatureServer/:layer/generateRenderer
2024-07-04T01:06:11.561Z info: ROUTE | [GET, POST] | /tc-file/rest/services/:id/FeatureServer/:layer/queryRelatedRecords
2024-07-04T01:06:11.562Z info: ROUTE | [GET, POST] | /tc-file/rest/services/:id/MapServer*

Setup for both was:

const Koop = require("@koopjs/koop-core");
const koop = new Koop({});
const provider = require("@koopjs/provider-file-geojson");
koop.register(provider, { name: "tc-file", dataDir });

package.json

"@koopjs/koop-core": "^10.4.15",
"@koopjs/provider-file-geojson": "^2.2.0",
"koop": "^5.1.1",

[rgwozdz]

No, sorry. FeatureServer routes are for use with ArcGIS clients, and our observation is that they clients don't work if the path to the service does not include rest/services. We did have both variations for a long time, but it kept causing confusing and bugs being logged like "Client doesn't work with my service..." because the developer wasn't using the route with rest/services.

[bamse16]

I forgot to mention that the links offered by the above project were used, in the maps created in the ArcGIS Portal, and with the ArcGIS SDKs (iOS/Android).

In our testing, the feature service URLs were working fine along the one including rest/services, so I don't really understand the issue with supporting both URLs, but it's up to you.