Closed CHOWY0152 closed 2 years ago
This would work even better now that we have CityJSON supported by SchemaStore. The some editors (like Visual Studio Code) could do on-the-fly validation by associating a file with our schema based on the file extension. Now, you can only do that if you manually set the "$schema"
property yourself.
What about .city.json
? It would clearly distinguish that we‘re dealing with CityJSON data, but all tools that don‘t know this format specifically would still know that it‘s JSON-based.
That's a good idea. But on the other hand, we have the already established practice of .geojson
in the geo field. I don't have a clear opinion.
That's a good idea. But on the other hand, we have the already established practice of
.geojson
in the geo field. I don't have a clear opinion.
I've also seen .geo.json
, but I have no idea how widespread each one is.
I don't think that enforcing an extension is a good idea at this point, but for the upcoming v1.1 I'll use myfile.city.json
for all the example files. Hopefully that will show the way to others.
Related to this, and perhaps more important, is the media type. As discussed in #84, registering a new media type would be sensible, and I'll investigate this. Probably application/city+json
is what makes the most sense.
It is not uncommon people work with multiple types of json files: generic json, ndjson (new line json), geojson and cityjson.
It would make sense if cityjson has its own file extension, so it is easily recognizable compared to other json files in a same directory.