That's just miscommunication caused by us, sorry! The "RESOURCES.md" does only contain helpful links and generic resources for working with map/geo data. We thought this could be helpful.
The actual source along with the complete build process is described in "SOURCE.md". Sorry for possibility of confusion!
Not sure if we should remove "RESOURCES.md" altogether or just rename it to make clear what these links actually are.
What if you make extracts, reprojections or create a new dataset from a ODbL-Licensed resources (or even more Licenses, depending on the number of datasets you use to create a new one), can you relicense it then?
First three norwegian cities I looked up was given the wrong name. (Plesund (should be Ålesund), Bodi (Bodø) and Tdnsberg (Tønsberg)). So, I think it is safe to say that there are encoding issues in the data set.
Looking at the SQL file, "Zürich" is listed as "Zdrich", Munich is only shown as "Munich" without the German name "München" anywhere, and Cologne is listed as "Cologne" with the wrong "Koln" as alternative name.
This is definitely a major problem that has to be fixed! Thanks for pointing this out again.
The complete build process is described in "SOURCE.md". That's where we got these encoding issues from -- right from the source material. Maybe we didn't open or parse the source material correctly. But we were not able to get them without the encoding errors.
So this is bascially Natural Earth repacked as JSON, CSV and SQL?
It's a nice start. I like it. Would it be possible to add the programm /instructions you used for converting the data from their original shape?
I would love to see an additional SQL version for PostGIS and the likes so that I can use their a large number of spatial functions to work with this data.
It seems to be the Natural Earth Dataset -- I think the 1:50m-resolution, but with a slightly reduced set of properties (columns). I haven't tried it, but from the looks of it, the sql-files should work with PostGIS as they are.
Exactly! Thanks. Although to some it may be "just Natural Earth", we thought it could be useful. JSON, CSV and SQL should be more helpful than the original shape files when building (web and mobile) applications.
We'll love to extend the data to make it ready for PostGIS etc. Will be useful!
We know that Apache, MIT, etc. are usually for code and the Creative Commons licenses are for content (e.g. writing, images).
We thought that the data sets (CSV, JSON, SQL) are rather in the intersection of code and content, so the Apache license would be okay.
Is there anything specifically wrong with the Apache license for this type of project? We couldn't find any tangible downsides but we'd love to hear about any pros and cons.
congratz, nice job! really interesting and helpful. I'll try to use it.
nowadays I am using sollo atlas (which is used by the http://www.findmyninja.io):
I've not see http://www.wemakemaps.com/ before, looks like a cool site, but whats with consistently referring to OpenStreetMap as OpenMap? and how about adding proper attribution on the OSM maps?
There are free airport lists that are much more complete. Also, two columns (lon, lat) for points would be better, as it's much easier to transform "lon, lat" into "POINT(lon lat)" than otherwise.
And, yeah, although I don't really care for licenses usually, here it makes me feel uneasy.
Cool! Do you have any plans to track historical changes of geospacial areas? What reference frame are you using for labeling areas? (places America considers countries vs what China considers, for example)
Thanks! Tracking historical changes is a great idea, but this requires perfect data from day one, doesn't it? Otherwise, how will you differentiate between historic changes and mere factual/technical corrections? Thus, right now, there are no plans to track this. But we're open to ideas and contributions on how to do this.
Regarding the reference frame, that's definitely an issue. Right now, it follows the souce's guidelines (see "SOURCE.md"), which means "boundaries of sovereign states according to defacto status. We show who actually controls the situation on the ground. For instance, we show China and Taiwan as two separate states. But we show Palestine as part of Israel."
Yeah, a quick perusal (VERY quick) revealed no provenance, maintenance, or currency information. There's a lot more to data than a snapshot of some tables.
[+] [-] rmc|10 years ago|reply
[+] [-] marco1|10 years ago|reply
The actual source along with the complete build process is described in "SOURCE.md". Sorry for possibility of confusion!
Not sure if we should remove "RESOURCES.md" altogether or just rename it to make clear what these links actually are.
[+] [-] funkysquid|10 years ago|reply
[+] [-] maze-le|10 years ago|reply
[+] [-] Quai|10 years ago|reply
[+] [-] bhaak|10 years ago|reply
Looking at the SQL file, "Zürich" is listed as "Zdrich", Munich is only shown as "Munich" without the German name "München" anywhere, and Cologne is listed as "Cologne" with the wrong "Koln" as alternative name.
Doesn't look like a reliable data source.
[+] [-] marco1|10 years ago|reply
The complete build process is described in "SOURCE.md". That's where we got these encoding issues from -- right from the source material. Maybe we didn't open or parse the source material correctly. But we were not able to get them without the encoding errors.
We'll love to fix all these issues :)
[+] [-] Vespasian|10 years ago|reply
It's a nice start. I like it. Would it be possible to add the programm /instructions you used for converting the data from their original shape?
I would love to see an additional SQL version for PostGIS and the likes so that I can use their a large number of spatial functions to work with this data.
[+] [-] maze-le|10 years ago|reply
[+] [-] funkysquid|10 years ago|reply
[+] [-] marco1|10 years ago|reply
We'll love to extend the data to make it ready for PostGIS etc. Will be useful!
[+] [-] jerrysievert|10 years ago|reply
at least the points are in WKT, so should be able to be converted into something useful.
[+] [-] legulere|10 years ago|reply
[+] [-] marco1|10 years ago|reply
We know that Apache, MIT, etc. are usually for code and the Creative Commons licenses are for content (e.g. writing, images).
We thought that the data sets (CSV, JSON, SQL) are rather in the intersection of code and content, so the Apache license would be okay.
Is there anything specifically wrong with the Apache license for this type of project? We couldn't find any tangible downsides but we'd love to hear about any pros and cons.
[+] [-] vezzoni|10 years ago|reply
http://atlas.sollo.io/atlas/api
it's possible to easily navigate through resources (places data) and, a helpful feature is its capacity to have synonyms.
[+] [-] aembleton|10 years ago|reply
[+] [-] marco1|10 years ago|reply
[+] [-] Crocode|10 years ago|reply
Numerous website use the Geonames dataset foe there work. (I also partisipated in this madness: http://www.wemakemaps.com/)
[+] [-] datamongers|10 years ago|reply
[+] [-] krick|10 years ago|reply
And, yeah, although I don't really care for licenses usually, here it makes me feel uneasy.
[+] [-] marco1|10 years ago|reply
What makes you feel uneasy about the license? We'll love to fix this!
Regarding the airport lists, we're definitely open to merging in more complete and accurate data.
[+] [-] IanCal|10 years ago|reply
[+] [-] marco1|10 years ago|reply
Three things we definitely wanted were (1) complete boundaries, (2) easiest programmatic access and (3) efficient collaboration.
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] mileszim|10 years ago|reply
[+] [-] marco1|10 years ago|reply
Regarding the reference frame, that's definitely an issue. Right now, it follows the souce's guidelines (see "SOURCE.md"), which means "boundaries of sovereign states according to defacto status. We show who actually controls the situation on the ground. For instance, we show China and Taiwan as two separate states. But we show Palestine as part of Israel."
[+] [-] electriclove|10 years ago|reply
[+] [-] spacemanmatt|10 years ago|reply
[+] [-] marco1|10 years ago|reply
As outlined in "SOURCE.md", one part of the update process should be to continuously compare to the latest Natural Earth data.
Apart from that, we're totally open to contributions and ideas from the community!