Show HN: Free database of geographic place names and geospatial data

https://github.com/delight-im/FreeGeoDB?hn=2015-09-25

by marco1 • 11 years ago

108 52 11 years ago

github.com

aembleton• 11 years ago

This would have been useful if the railroads and roads actually had names attached to them.

marco118• 11 years ago

We didn't get those from our sources but we'll love to add them!

IanCal• 11 years ago

Looks interesting, how would you compare it to GeoNames?

marco118• 11 years ago

Admittedly, it's similar! But we wanted to include more data, other data, and just offer an alternative in general.

Three things we definitely wanted were (1) complete boundaries, (2) easiest programmatic access and (3) efficient collaboration.

Vespasian2• 11 years ago

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.

maze-le4• 11 years ago

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.

maze-le4• 11 years ago

Actually, according to the resource-file is isn't Natural Earth after all. The column-names almost fit the NE-Datasaet though...

Vespasian2• 11 years ago

For what I've seen the data type of the columns is always varchar and not geometry.

Not a big issues merely it's more convenient otherwise ;)

marco118• 11 years ago

You're right! Please see the "SOURCE.md" file for all necessary information. Sorry for not linking this file in a prominent place!

jerrysievert• 11 years ago

unfortunately, while it is in JSON, it is not in GEOJSON, nor anything that appears to be standard.

at least the points are in WKT, so should be able to be converted into something useful.

marco118• 11 years ago

Thank you! We'll love to hear and discuss what's the best way to represent and store the data. We're open to changes between GeoJSON, WKT, etc.

funkysquid2• 11 years ago

Looks like they include instructions on how to build in SOURCE.md (https://github.com/delight-im/FreeGeoDB/blob/master/SOURCE.m...) - would be great to have that linked in the README though.

marco118• 11 years ago

Thanks! We'll have to add a link to the README, you're right!

marco118• 11 years ago

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!

rmc4• 11 years ago

"RESOURCES.md" ( https://github.com/delight-im/FreeGeoDB/blob/master/RESOURCE... ) includes OpenStreetMap, which is licenced under the Open Database Licence (ODbL). You cannot relicence it under the Apache licence. I've raised an issue ( https://github.com/delight-im/FreeGeoDB/issues/1 )

maze-le4• 11 years ago

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?

Doctor_Fegg• 11 years ago

This is known as a "Derivative Database" and so ODbL still applies. It's a classic share-alike/copyleft licence, with the wrinkle that it has to use copyright, database rights, and contract law because database protection varies across legislations. See http://opendatacommons.org/licenses/odbl/ .

rmc4• 11 years ago

No. That's a derived database, and would be under ODbL.

marco118• 11 years ago

Interesting question! You've got the replies already. Just wanted to clarify that this issue does not affect FreeGeoDB.

funkysquid2• 11 years ago

It seems like OpenStreetMap is not actually the source for the data - https://github.com/delight-im/FreeGeoDB/issues/1#issuecommen...

marco118• 11 years ago

This is true! Thank you!

marco118• 11 years ago

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.

legulere• 11 years ago

Apache seems a strange license for data. Why not CC-0 like for instance wikidata?

marco118• 11 years ago

Thank you!

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.

pki• 11 years ago

data sets are simply that - data - content

your code would be the scripts you write to process it, and your content would be your data in my opinion

Quai• 11 years ago

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.

bhaak2• 11 years ago

There's definitely something wrong.

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.

seszett• 11 years ago

French names have the same problem, with "La Réunion" being shown as "La Rcunion" and "Rhône-Alpes" as "RhAne-Alpes".

It's strange, I can't really understand how these accents can get mangled as these particular single letters.

maze-le4• 11 years ago

It's 2015 and we still have UTF-8 problems... sigh

marco118• 11 years ago

Sorry for the inaccuracies!

We'd love to fix all those issues -- maybe with some help from the community :)

The goal is definitely to turn this into a more and more reliable data source every day.

marco118• 11 years ago

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.

We'll love to fix all these issues :)

lobster_johnson• 11 years ago

Instead of Markdown file, you should consider creating a set of scripts that will fetch, cache and process upstream data into the desired formats. As someone interested in using this data, I really need to be able to easily run the entire build process myself.

krick• 11 years ago

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.

marco118• 11 years ago

Thank you!

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.

electriclove• 11 years ago

How will this be kept up-to-date?

spacemanmatt2• 11 years ago

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.

marco118• 11 years ago

Thanks for reminding us of the importance of efficient updates!

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!

vezzoni• 11 years ago

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):

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.

Crocode• 11 years ago

The data like these are available for free (and updated by community!) for years. See http://www.geonames.org/

Numerous website use the Geonames dataset foe there work. (I also partisipated in this madness: http://www.wemakemaps.com/)

datamongers• 11 years ago

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?

mileszim• 11 years ago

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)

marco118• 11 years ago

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."

Show HN: Free database of geographic place names and geospatial data

Related Stories