OK, I will go for SpatialJSON.
I will now do the following:
* Rename all items according to SpatialJSON
* Throw an exception if the result contains complex features
* Update README.md and provide *.rst files in
doc/en/user/source/community/spatialjson
* Provide file ext-spatialjason.xml in src/community/release
* Add required profiles in src/community/pom.xml
* Provide a new (vanilla/)/ branch / PR
Did I forget anything?
BTW, I did not yet see any Zip files when doing a nightly build like so:
mvn package -P communityRelease
Is that a Windows issue? How to invoke Maven in order to build the
plugin Zip files?
Cheers
Carsten
Am 12.10.2022 um 09:46 schrieb Andrea Aime:
All the names work for me, if you like SpatialJSON go for it. Let's
get this one rolling :-D
Cheers
Andrea
On Tue, Oct 11, 2022 at 8:07 AM Carsten Klein <c.kl...@datagis.com> wrote:
Hello Andrea and Jukka,
you've seen the mail from Howard Butler. What to make out of it? He
doesn't like such "extended" formats (which I do understand) but also
recognizes that he's not in a position to actually do anything
against it.
For my mind, there are these options for the community plugin's name:
- Slim GeoJSON
- Tiny GeoJSON (in order to line up with Tiny WKB)
or more defensively
- SpatialJSON,
omitting Small/Thin/Slim/Tiny as SpatialJSON is a new format which
inherently is more compact and space optimized than GeoJSON. (Thanks
Andrea for the "Spatial" idea.)
As I'm not really interested in inventing and promoting a new cool
format, I could be quite fine with SpatialJSON.
What do you think about it?
Cheers
Carsten
Am 10.10.2022 um 14:40 schrieb Howard Butler:
> Carsten,
>
> Given the tone of your email and the fact that you are writing
it, I think you probably know what our answer will be. It is a new
format. It is not compatible with GeoJSON and any other GeoJSON
reader is going to fail reading it. It is not GeoJSON, and it
seems like disingenuous marketing to call it a similar name in my
opinion.
>
> It is totally fine to be making these optimizations and trying
to proliferate them. You are definitely not the first to try.
GeoJSONL would seem to be related to your approach. You could also
look at FlatGeoBuf, which has GeoServer support, but gives up on
JSON to have more features. Or wait for OGC to come out with their
"new and improved GeoJSON" in the form of OGC Features API output,
which adds even more capability.
>
> I don't like formats that are "kind of like GeoJSON but not
compatible" trying to leverage GeoJSON's marketing reach, and this
includes things like GeoJSONL, SlimGeoJSON, and OGC's effort,
which they tried to call it "Enhanced GeoJSON", as if it needed
enhancement. GeoJSON is not internationally trademarked, and it
cannot really stop these efforts from trying to trade on its name.
However, "GeoJSON" is such a generic term it probably could not
obtain a trademark, and other efforts calling themselves something
that looks like it could not be stopped in any official capacity
anyway.
>
> In closing, you can call it what you like. Naming things is
really hard :)
>
> Howard
>
>
>> On Oct 10, 2022, at 1:31 AM, Carsten Klein
<c.kl...@datagis.com> wrote:
>>
>> This format adds only two small changes to GeoServer's GeoJSON
format (the version before RFC 7946). Nevertheless, these changes
make it incompatible with regular GeoJSON and actually make it a
new format. Other optimizations may come on top in the future.
>>
>> Primarily, I need that format for my own projects, in which web
based clients may request some thousands of features, each with
approx. 450 fields/properties. Here, omitting repeated property
names actually saves up to 70% of space (~ 50% transfer size).
>>
>> Suggested by the GeoServer team, I'm asking you whether you
would agree that I name this new format something like "Slim
GeoJSON" or "Tiny GeoJSON" (see. Tiny Well Known Binary, TWKB)
prior to releasing anything to the internet.
>>
>> Since the new format is actually based on GeoJSON with only two
small (but, of course, incompatible) changes, I'm really in favor
for a name which still includes the ´GeoJSON´ term.
>
>
--
Regards,
Andrea Aime
==GeoServer Professional Services from the experts!
Visit http://bit.ly/gs-services-us <http://bit.ly/gs-services-us>for
more information.==Ing. Andrea Aime @geowolfTechnical Lead
GeoSolutions Groupphone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
https://www.geosolutionsgroup.com/ <https://www.geosolutionsgroup.com/>
http://twitter.com/geosolutions_it <http://twitter.com/geosolutions_it>
-------------------------------------------------------
Con riferimento alla normativa sul trattamento dei dati personali
(Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati
“GDPR”), si precisa che ogni circostanza inerente alla presente email
(il suo contenuto, gli eventuali allegati, etc.) è un dato la cui
conoscenza è riservata al/i solo/i destinatario/i indicati dallo
scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a
cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato
se potesse darmene notizia.This email is intended only for the person
or entity to which it is addressed and may contain information that is
privileged, confidential or otherwise protected from disclosure. We
remind that - as provided by European Regulation 2016/679 “GDPR” -
copying, dissemination or use of this e-mail or the information herein
by anyone other than the intended recipient is prohibited. If you have
received this email by mistake, please notify us immediately by
telephone or e-mail
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
