1.0.0 release

[cholmes]

Ok, I think we're about ready to go with the 1.0.0 release! I'm going to look for everyone with write access to approve this PR.

I updated the readme in a few ways:

• Removed warnings about not quite being 1.0.0
• Made it a bit more clear the links to the repo are the 'dev' version, and the version on the website is the one to use.
• Put links into the two validators that do actual data checks (happy to add more here too).

One question I had is if we should remove the validator that's in this repo to not be here. I've leaned towards that as it's cleaner, but I don't feel quite qualified to put it in its own new repo. If someone (@kylebarron? @alasarr?) would be up to move it that'd be ideal - I can make a spot for it in the https://github.com/geoparquet org. I also could just remove it from this repo and we can add it in later if others are comfortable with that. I'm also fine to just leave it here - it's not referenced on the front page. But we probably should clarify that it just tests the metadata.

I didn't yet 'tag' the release, as per instructions on https://github.com/opengeospatial/geoparquet/wiki/Release-Process but can when we're ready.

The other 'nice to have' thing for release would be to publish the 'parquet geospatial compatibility' doc (https://github.com/opengeospatial/geoparquet/blob/main/format-specs/compatible-parquet.md) on the website. But I'm ok if we just figure that out later.

[TomAugspurger]

I haven't kept up with the mechanics of releases, but the text updates look good to me.

One question I had is if we should remove the validator that's in this repo to not be here.

This makes sense to me. I think it's fine to move to a new repo in the geoparquet org, and it can be done at any time (if people need it, they can clone an older tag of this repo).

[Jesus89]

In this branch, we should update geoparquet_validator/schema.json

from

  "properties": {
    "version": {
      "type": "string",
      "const": "1.0.0-dev"
    },

to

  "properties": {
    "version": {
      "type": "string",
      "const": "1.0.0"
    },

Let me know if you want me to create a PR over this branch.

[cholmes]

In this branch, we should update geoparquet_validator/schema.json

Ah, sorry for missing it. But I think I'm just going to remove the validator as discussed above.

[cholmes]

This makes sense to me. I think it's fine to move to a new repo in the geoparquet org, and it can be done at any time (if people need it, they can clone an older tag of this repo).

Just removed the validator. Will try to add it elsewhere soon.

[cholmes]

Hrm - the downside of remove the validator is that the build can then no longer validate the examples... Guess the ideal is to put in another package that the CI would just download and use?

[m-mohr]

The release looks fine.

I'm a bit out of the loop and just out of curiosity: The repo is hosted under the OGC, doesn't an OGC release need to follow some kind of OGC procedure for a release? Or are we independant to release whenever we want?

[Jesus89]

Hrm - the downside of remove the validator is that the build can then no longer validate the examples

Correct, I would rather keep the utility until there is an external package to replace in CI. That package would depend on the format-specs/schema.json file present in this repo, so it would require either a submodule, a link or duplicating the JSON for a specific version.

[kylebarron]

I don't have a strong preference on where the validator should live. Maybe it should be in its own repo that can be published to PyPI as something like geoparquet_validator?

[ghobona]

@cholmes At some point, when the geoparquet validator is ready, I would like to explore integrating it into the OGC Compliance Program. So an option is to create the validator's repository in the opengeospatial GitHub organization. Please let me know if you would like the repository created in the opengeospatial GitHub organization.

[cholmes]

I'm a bit out of the loop and just out of curiosity: The repo is hosted under the OGC, doesn't an OGC release need to follow some kind of OGC procedure for a release? Or are we independant to release whenever we want?

Afaik the ogc repos are independent of their overall process. The official standardization process isn't in github at all, it's submitted documents and voting.

[cholmes]

Hrm - the downside of remove the validator is that the build can then no longer validate the examples
Correct, I would rather keep the utility until there is an external package to replace in CI. That package would depend on the format-specs/schema.json file present in this repo, so it would require either a submodule, a link or duplicating the JSON for a specific version.

So I just went ahead and removed the validation job. My reasoning is that I think we should move away from having examples in the spec repo, and we won't be changing the spec that much. But I'm fine for pushback that we should put it in its own package and get it all hooked up to CI - but I'd like that pushback to be accompanied by a commitment to do the work. From my perspective we have good external validation tools. The big reason to have this working well in CI is to ensure if we're doing extensive work on the spec then the examples are all up to date, but I see that as just necessary before we start any major work.

[cholmes]

@cholmes At some point, when the geoparquet validator is ready, I would like to explore integrating it into the OGC Compliance Program. So an option is to create the validator's repository in the opengeospatial GitHub organization. Please let me know if you would like the repository created in the opengeospatial GitHub organization.

So we have 2 validators that are quite 'ready' - gpq and the gdal script. This validator never actually validated the data, just the metadata. So I'd start with one of those for the compliance program. I think it makes less sense in the OGC github as there's just so much there - prefer it to be 'grouped' with other geoparquet tools.

[ghobona]

Thanks @cholmes . We'll review the gpq and gdal script.

[tschaub]

Thanks for putting this together, @cholmes. The changes look good to me.

[paleolimbot]

Thanks to everybody for the hard work to get to this point! I think these changes are well thought-out to focus the intent and scope of the 1.0.0 release. Looking forward to the announcement!

[alasarr]

Amazing to see this is finally out! It has been an amazing ride!

I agree with the idea of moving the validator outside of the repo and publish a geoparquet_validator package at PyPI.

[alasarr]

Amazing to see this is finally out! It has been an amazing ride!

I agree with the idea of moving the validator outside of the repo and publish a geoparquet_validator package at PyPI.

[jatorre]

Thank you @cholmes for organizing this. It looks good to me. I hope this is the start of a great and widely use standard. Thanks all for the work.

And can’t wait to start looking at 1.1 😉