https://defs.opengis.net/ is a 404

[jerstlouis]

The root of the definition server URL is a 404:

https://defs.opengis.net/ https://defs.opengis.net/def/

It is still very difficult to find things on the definitions server, whether from a Google search or trying to browse the server itself. The definitions from the OGC definition servers rank low on Google searches, possibly for reasons such as this.

As well as the Standards implementers/developers, the Standard editors would like to use the definition servers all the time to find / validate things and progress faster on the standards (e.g., the OGC APIs).

Related to #23 ?

[rob-metalinkage]

Thanks @jerstlouis

We'll look at the design as part of the UI upgrade over the next months and stand up a dedicated git repository for the UI configuration and seek feedback on alpha and beta versions. Will fix 404 and update intro page in the meantime. Specs are now linked to SWGs.

In general it will help to understand the starting point. When we have a decent UI we'll link from the main OGC summaries to the knowledge graph.

Please contact us for a link to a spreadsheet to review and edit any SWG and inter-spec links we haven't been able to guess.

[ghobona]

Officially the landing page of the definitions server is https://www.opengis.net/def/

@rob-metalinkage I would prefer that we set up a redirection rule from https://defs.opengis.net/ to https://www.opengis.net/def/

@jerstlouis How did you come across https://defs.opengis.net/def/ ? If it is in an OGC document, then it is a typo that should be corrected.

[rob-metalinkage]

Agreed let's not duplicate content ! Needs a What's new feed set up to feed this.

[jerstlouis]

@ghobona

@jerstlouis How did you come across https://defs.opengis.net/def/ ?

Sorry, that was probably just me being confused trying to find where the landing page is, which was kind of the problem with the confusion of the redirects from:

https://www.opengis.net/def/

to:

https://defs.opengis.net/vocprez/

With recently accessed definitions in the browser address bar and trying to remove path components to go to the landing page, this does not work because of the re-directs to somewhere else.

With Apache mod_proxy for example proxying to https://defs.opengis.net/vocprez/ , the definition server could just always keep https://www.opengis.net/def/ in the URL address bar and then one could simply remove path components to go up to the landing page.

Re-directing from https://defs.opengis.net/ to https://www.opengis.net/def/ would fix this particular issue, but he latter then re-directs to https://defs.opengis.net/vocprez/ which is what #112 was about but it was closed.

I don't know if a UI upgrade is really necessary to address this, or if Apache/mod_proxy proxying to vocprez could fix all this? The issue is that the https://defs.opengis.net/vocprez/ paths are an implementation detail of the definition server which ideally users accessing definitions do not need to see / should not see in my opinion.

Thanks for looking into all this.

[rob-metalinkage]

URL hacking is not really a robust approach - its more important we fix things so that pages you need are always visible in the UI.

No significant portal expects you to do URL hacks - and most will do a redirect.

That said - everything in any path both before and after redirects should resolved somewhere useful to meet a general idea of REST resources.

[jerstlouis]

@rob-metalinkage I don't think what I am suggesting is "URL hacking", but separation of any restrictions to specific paths enforced by the implementation (https://defs.opengis.net/vocprez/ etc.) from the fact that normally REST resources organized starting from a landing page at https://www.opengis.net/def/ and with canonical URIs using that as a base path, should not require to re-direct the user anywhere else than within that URL directory tree.

From my own point of view this redirection to non-canonical path is still by far the single biggest issue with the definition server and it is a problem on a daily basis, several times a day. Proxying from https://www.opengis.net/def/ to https://defs.opengis.net/vocprez/ might be an easy way to solve this, if it requires a lot of efforts to have vocprez handle responses directly within the https://www.opengis.net/def/ tree without re-directs.

As for the UI, the browser's address bar is the single most important part of the UI in terms of how I personally use the definition server:

• I use the Browser's Address Bar to start accessing the definition server,
• I use the Browser's Address Bar to enter a URI to validate,
• I use the Browser's Address Bar to use a recently accessed URI,
• I use the Browser's Address Bar to move up to a parent resource,
• I use the Browser's Address Bar to do a "copy" to get the validated and/or browsed-to URI of the resource of interest

So regardless of any improvements to the content of the pages themselves, if re-direction outside www.opengis.net/def still happens, those usability concerns will not have been addressed.

The only time I use the content of the page itself is to see the sub-paths and click one of them to browse to a child resource. On this note, it would be nice to see not only identifiers but also a short "title", and have an HTML view for pages like:

• http://www.opengis.net/def/method/EPSG/0
• http://www.opengis.net/def/crs/EPSG/0
• http://www.opengis.net/def/datum/EPSG/0

to make it easier to find the CRS / method / datum you're looking for.

( as for other portals re-directing you all over the place, they are a pain, but not nearly as important as the OGC definition server :) )

These expectations are also in-line with OGC API implementations e.g., https://demo.pygeoapi.io/, https://demo.ldproxy.net/, https://maps.gnosis.earth/. They don't re-direct the users to a path outside of their landing page for resources that they are themselves providing.

[rob-metalinkage]

@jerstlouis most of these usage patterns are on the radar for ui redesign and should not require typing as a solution. We need to explore more browser behaviour re bookmarking and history. There is a rel=canonical ietf option but browsers didn't respect these last time I played. Will revisit. Will also explore a squid cache option too.

In general stopping people caching the redirect or relying on a url is important I agree.

[avillar]

@jerstlouis, the URL issue that you mention will be somewhat solved in a version of the Definitions Server UI that is currently in the works.

For now, IMHO the best course of action is to redirect users from both https://defs.opengis.net/ and https://defs.opengis.net/def/ to https://www.opengis.net/def/ like @ghobona proposes.

[avillar]

Redirection enabled for defs.opengis.net. Closing this issue; reopen if necessary.