| esbranson added a comment. |
In T57549#611130, @Lydia_Pintscher wrote:We should look into using http://leafletjs.com for this.
This is out of scope. Once we are able to input, store, and output spatial data, we can turn to using it. One foot in front of another.
In T57549#1088276, @Lydia_Pintscher wrote:@Kolossos: You're making a very good point about geojson very likely being too big. Do you have recommendations for other ways to store it?
We should use whatever method that's been used by every other project using spatial data, and that likely means, well, a regular database (spatial extensions were integrated into the main trees long ago). MySQL and MariaDB are no stranger to spatial data. Unless technical constraints are identified, we should not impose arbitrary constraints.
In T57549#1090333, @Kolossos wrote:In T57549#1088276, @Lydia_Pintscher wrote:@Kolossos: You're making a very good point about geojson very likely being too big. Do you have recommendations for other ways to store it?
I see two option:
*Handle it Geodata like a file and allow uploads of KML/GPX/GeoJSON to Commons.
*Handle it in a Geo-database (Postgresql/PostGIS) where you could make complex queries, etc.I would prefer the second way. We have also to keep in mind that some geodata are not only big but have also a complex structure, so e.g. the border of russia is composited from different parts (border to Country A, border to Country B, ...) and you want to reuse these elements to define e.g the order of Country A.
OpenStreetMap datastructure can handle such things by using Nodes,Ways and Relations. And we know how we can link between both projects from WIWOSM. Also for Queries we have software with Overpass-API/Overpass-turbo.
On the other side the maintaining of a full OSM software stack seems more complex than the file based approach.
I think the data should be stored in the underlying database, using whatever format the underlying database uses, and allow input of any format which can be converted to it. I think that means WKT/WKB in the database, and allowing most formats as input/output, but this should be left to the assigned implementer. If the assignee finds it easier or somehow better to store this underlying data on a sister project, then OK, but otherwise the suggestion seems unnecessarily complicated.
In T57549#1091100, @Rschen7754 wrote:Enforcing a conversion to a geodatabase format without any migration path is not a good idea, however, and will lead to the loss of data or a reluctance to migrate data to Wikidata.
I say we use the current de facto migration path to migrate data from external projects to Wikidata, e.g., from Wikipedia or Commons. My understanding is that this is ad hoc, but again I think this is out of scope.
In T57549#611120, @Rschen7754 wrote:Add support for geoshapes as a datatype to Wikidata, to accurately represent linear and polygon geographic objects.
Again, I say using WKT/WKB in the database, and allowing most formats as input/output. It's been several years since we've known we'd need this. This is blocking numerous likely properties. The longer we wait, the more work will be required to actually implement this and we will also need to merge this into changes like T123565 and all future changes made in this domain. This is blocking pretty much every non-point geographic dataset and their integration not only in Wikidata but Wikipedia as well. Project leadership needs to step up and lead.
Cc: RolandUnger, Boshomi, Susannaanas, Christopher, Yair_rand, Kopiersperre, putnik, StudiesWorld, esbranson, DixonD, Aklapper, Sannita, Ricordisamoa, Cavila, Rits, Niharika, Kolossos, El_Grafo, Wikidata-bugs, Tobias1984, aude, Rschen7754, Liuxinyu970226, Ainali, Lydia_Pintscher, D3r1ck01, Izno, TheDJ, Mbch331
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
