Comments (16)
I've filed an issue at RtD at readthedocs/readthedocs.org#11223 . Let's see if we get some response
from proj.
still in brainstorming mode... Given that the desired resource is /schemas/v0.7/projjson.schema.json, this could ressemble the RTD versioning scheme used for PROJ content (/{language}/{version}/foo) if we'd use language=schemas and version=v0.7. But that looks super messy and not sure we can invent an arbitrary language name and somehow mix PROJ versions with schema versions.
from proj.
Ah that's an oversight. Just updated to https://proj.org/schemas/v0.7/projjson.schema.json per 5f725fb (master branch) and 0caf671 (9.4 branch)
Regarding CORS issues, I'm not familiar with that. The thing is that now we use ReadTheDocs versionned docs, and no longer a static (single version) github hosted website. And so we have a global redirect from /{foo}
to /en/latest/{foo}
in the ReadTheDocs settings. CC'ing @mwtoews if he has some clues on what we could do.
An alternative would be that you and us now reference https://proj.org/en/latest/schemas/v0.7/projjson.schema.json as the official URL (assuming it has the CORS headers?)
from proj.
wondering if using RTD sub-projects (https://docs.readthedocs.io/en/stable/subprojects.html) couldn't be a solution. If we had a "schemas" sub-project, only fed from master builds, that might perhaps do it
from proj.
One solution is to use the replacements extension that uses a mapping configuration which is used in a few places like here. This would require this one variable PROJJSONVERSION to be configured in conf.py with notes to maintain it for each release.
from proj.
One solution is to use the replacements extension that uses a mapping configuration which is used in a few places like here. This would require this one variable PROJJSONVERSION to be configured in conf.py with notes to maintain it for each release.
@mwtoews Not sure to follow you. How would that help having https://proj.org/schemas/v0.7/projjson.schema.json to be a CORS friendly URL? What you propose if I've understood would be more to help keeping track of the latest version of the projjson spec, but hopefully it won't change very frequently at that point.
from proj.
An alternative would be that you and us now reference https://proj.org/en/latest/schemas/v0.7/projjson.schema.json as the official URL (assuming it has the CORS headers?)
Unfortunately, we can't update released specification schemas. We can do that in new versions, but STAC 1.0.0 and GeoParquet 1.0.0 will both keep referencing the old version and will fail forever. As such I'd be happy if a solution could be found.
An alternative would be that you and us now reference https://proj.org/en/latest/schemas/v0.7/projjson.schema.json as the official URL (assuming it has the CORS headers?)
Yes, it has.
The other question is, is it really good if the schemas are versioned twice / available at dozens of locations?
-> https://proj.org/en/9.4/schemas/v0.5/projjson.schema.json
-> https://proj.org/en/9.3/schemas/v0.5/projjson.schema.json
-> https://proj.org/en/latest/schemas/v0.5/projjson.schema.json
-> ...
Which shall a user use? Maybe the schemas should not live within the versioned documentation and be hosted separately?
from proj.
is it really good if the schemas are versioned twice?
Well, that hasn't been specifically designed. That's a consequence of having the versioning of the schemas in the /schemas of the git repo (https://github.com/OSGeo/PROJ/tree/master/schemas), and deploying it when building the documentation of a given branch. As RtD adds versioning of the PROJ branches on top of that, you get those 2 levels of versioning.
Referencing to the /latest/is most certainly preferable, in the hopefully unlikely case there would be a need to patch a released version of the schema, instead of publishing a new one.
But maybe we can find a solution to have back the old URL in a CORS friendly way. We just need to figure out if that's possible.
In brainstorming mode: https://raw.githubusercontent.com/OSGeo/PROJ/master/schemas/v0.7/projjson.schema.json is also a candidate CORS compatible URL, but less "good looking".
from proj.
Thanks, but the new URLs have CORS. The issue is that the old URLs are baked into specs and can't really be changed. As such the only solution can be that the old URLs get CORS support, and/or we remove the rediect for the schemas and/or we move the files back to the original place. The alternative is leaving it broken, but I hope there's a better solution. A new URL variant wouldn't help due to the reason given above.
What's responsible for the redirects? We need to hook into there, I think.
from proj.
What's responsible for the redirects? We need to hook into there, I think.
This is this RtD mechanism: https://docs.readthedocs.io/en/stable/user-defined-redirects.html#user-defined-redirects
In https://readthedocs.org/dashboard/osgeo-proj/redirects/20195/edit/ we have setup an "exact redirect" from /schemas/*
to /en/latest/schemas/:splat
using HTTP 302. What is done underneath is somewhere in the RtD sources... Probably somewhere in https://github.com/readthedocs/readthedocs.org/tree/main/readthedocs/redirects
from proj.
I was about to do the same, thank you @rouault!
from proj.
wondering if using RTD sub-projects (https://docs.readthedocs.io/en/stable/subprojects.html) couldn't be a solution. If we had a "schemas" sub-project, only fed from master builds, that might perhaps do it
Personally, this seems like a nice solution?
That should allow to restore the actual URLs without any redirection, and also keeps the URLs somewhat more independent from the readthedocs versioning scheme if also for future versions of the spec we keep using the old URL structure (you never know if in the future the hosting of the docs is again migrated)
from proj.
Personally, this seems like a nice solution?
actually, looking at https://docs.readthedocs.io/en/stable/subprojects.html, I think it is a wrong track as URLs are like https://docs.example.com/projects/{subproject_name}/en/latest/
, so that wouldn't help
from proj.
Ah, indeed, all the examples indeed include "projects" as first part of the url after the main domain ..
from proj.
@m-mohr If readthedocs/readthedocs.org#11223 fixes your issue, we can close this issue, right?
from proj.
Indeed, this works fine now. Thanks a lot!
from proj.
Related Issues (20)
- Transformation without Grid Shift HOT 1
- Transform X,Y,Z from source to dest with approximate Grid Shift HOT 3
- Controlling Grid Shifts (PROJ-data) size by selecting resolution HOT 3
- geod should add cct's "-c" option, to finally allow it to also accept lon,lat input order HOT 1
- Support for EPSG methods 9666 and 1049 HOT 4
- Windows installer is broken HOT 2
- cct --help out of step with man cct, still shows "+step +step"
- `"-` artifact in rendered cct man page HOT 4
- Proposed enhancement for command-line interface tests HOT 3
- Ogr2ogr: Confusing error when source crs is unknown HOT 3
- GDA94 to GDA2020 horizontal shift fails when using EGM2008 & EGM96 vertical crs HOT 3
- Concatenated operation with height reversal fails HOT 2
- depth to depth or two CRS with orientation down issue? HOT 3
- Link PROJ to CMAKE HOT 3
- Transformation from Gauß Krüger (EPSG:31256) coordinates to WGS84 (EPSG:4326) ? HOT 2
- JOYr2
- Update to ESRI projection db available
- User writable directory HOT 2
- prj with "local" projection from ArcGIS HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from proj.