<br><br><div class="gmail_quote">2010/1/6 Lennard <span dir="ltr"><<a href="mailto:ldp@xs4all.nl" target="_blank">ldp@xs4all.nl</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>> but I think the NGI won't even consider doing that. In the import<br>
<br>
</div>It's certainly worth it to ask and explore this, before we turn all our<br>
attention to CLC2000.<br>
<br></blockquote><div> </div><div>I have contacted them: let's see what comes of it...<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><br>
> section they describe how to do it.<br>
> Do you all think it is worth it?<br>
<br>
</div>I have the entire CLC2000 dataset on my server, and had a quick look. The<br>
answer is, obviously: "yes and no".<br>
<br>
Con: The data is old, some things will simply be outdated.<br>
<br>
Pro: Some objects, like residential landuse areas, look pretty good. All<br>
the typically belgian 'linten' are very recognisable.<br>
<br>
Con: Other objects, like agricultural areas, are pretty large, and would<br>
certainly not form a single continuous area IRL. This would need extra<br>
checking after the import.<br>
<br>
Pro: landuse mapping in Belgium, outside where there is yahoo hires<br>
coverage and people have spent time tracing, is pretty lacking. Taking the<br>
specific things from CLC2000 that would work nicely would be a good step<br>
forward.<br>
<br>
Pro: the way the French have setup the Corine import is that you can<br>
exclude areas which are overlapping with existing OSM areas. You can then,<br>
later on, import those areas missed due to overlap, by hand, from a<br>
website. Ben said we could even delete existing OSM areas before the<br>
import starts, if we know the existing mapping is inaccurate.<br>
<br>
If you guys want, I could set up a map overlay with the raw CLC2000 data,<br>
so you can check it out?<br></blockquote><div><br>The map overlay would be handy. <br>Appartenly the corine dataset consists only of chuncks that are at least 25ha in size: that means that you cannot expect too much detail out of it, which in turn favours the fact that we should retain the manual data above Corine data, but on the other hand makes the dataset robust towards changes, especially in Belgium, so I guess that the changes between 2000 and 2006 will not be dramatic.<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><br>
> I have got some more plans, but I promise I want do any bulk uploads<br>
> without consulting you ;-)<br>
<br>
</div>Do you have any other potential datasets in mind?<br></blockquote><div><br>Another example is the clean-up of the place-key. Right now this is a mess: some have postal_code attached some have not, some have an is_in tag some not.<br>
Right now I have downloaded all the place-key in belgium (which involved downloading all the boundaries of belgium and testing whether the places I got were in that disconnected polygon :-o )<br>On <a href="http://www.post.be/site/nl/residential/customerservice/search/postal_codes.html" target="_blank">http://www.post.be/site/nl/residential/customerservice/search/postal_codes.html</a> you can download postal code of municipalities and sub-municipalities per province, which gives you a nice hierarchical overview of the Belgian state structure. This will at least allow me to <br>
- create a list of the missing municipalities and sub-municipalities (from now on called muns)<br>- create a list of the unknown or misspelled muns in OSM<br>- create consistent information for all of the muns which are already present in OSM (eg population for muns Flanders can be found on <a href="http://www.binnenland.vlaanderen.be/statistieken/excel/inwoners%20gemeenten.xls" target="_blank">inwoners%20gemeenten.xls</a>
)<br><br>The question is what do we do with muns not present in OSM?<br>There are a number of sources we could use to generate them from:<br>- The geonames from the US military databases which have no copyright attached <b><a href="http://www.nga.mil/" target="_blank">www.nga.mil</a></b>. This has been used previously in OSM.<br>
- another one is this link <a href="http://www.rdlt.com/postcodes-van-alle-gemeentes-van-belgie-met-gps-coordinaten">http://www.rdlt.com/postcodes-van-alle-gemeentes-van-belgie-met-gps-coordinaten</a><br>But where does the data come from? Can we use it?<br>
- On the website <a href="http://www.hisgis.be/">http://www.hisgis.be/</a> you can find detailed shp files, which are copy-righted but I think we can use them to curate the data in one or both of the previous datasets. Since we only use the data but not publish it, I think there is no legal problem.<br>
<br>We must also think about the nomenclature<br>If you look at <a href="http://tagwatch.stoecker.eu/Belgium/En/keystats_place.html">http://tagwatch.stoecker.eu/Belgium/En/keystats_place.html</a> you see that there are 321 towns and 1642 villages. There are even 14 cities, which means according to <a href="http://wiki.openstreetmap.org/wiki/Key:place">http://wiki.openstreetmap.org/wiki/Key:place</a> +100000 inhabitants!<br>
Personally I would ignore that guideline completely because it is solely based on # of inhabitants. As is clearly explained in <a href="http://en.wikipedia.org/wiki/List_of_municipalities_of_Belgium">http://en.wikipedia.org/wiki/List_of_municipalities_of_Belgium</a>, municipalities and sub-municipalities reflect the Belgian state structure more closely. We could of course map city to muns > 100000, towns to other muns and villages to sub-muns, but that will not be true always (i.e. Herstappe is a mun with 84 inhabitants!)<br>
But that is my opinion: this issue is certainly open to discussion.<br><br>That way I hope to get the place-key curated soon. If you have any remarks about methodology or sources, please feel free to email. Is there a server I can put files, programs and such on? That way discussion might be more concrete...<br>
</div></div><br>So long,<br><br>Kenny aka Pietje Leugenaar<br>