<div dir="ltr"><div><div><div>Thanks for your responses :)<br></div>and yeah i totally agree that an import is probably not a good idea, <br></div>but i was thinking more like a map  of missings schools or streets without surface  (with one in the dataset)<br></div>and with ideally a "one-click" import ( 1 feature by 1 feature)<br><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">2018-04-04 11:04 GMT+02:00 Glenn Plas <span dir="ltr"><<a href="mailto:glenn@byte-consult.be" target="_blank">glenn@byte-consult.be</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 03-04-18 21:22, eMerzh wrote:<br>
> Hi all :)<br>
><br>
> I'm just discovering the data sets that are in<br>
> <a href="http://opendatastore.brussels/" rel="noreferrer" target="_blank">http://opendatastore.brussels/</a><wbr>  (brussels region)<br>
> and some of them might be really interesting for osm.<br>
> Like :<br>
> - school list<br>
> - streets surfaces<br>
> - 3d buildings<br>
> - parkings<br>
> - transports stop poles<br>
> and much more<br>
><br>
> , but I was wondering if there was an "easy" way to do the<br>
> conflation... automatically or semi-manually ...<br>
> for now the only way I see is to transform data, put them in a<br>
> postgis  then doing all the work manually... but...<br>
> ** there must be a better way **<br>
> no?<br>
<br>
</div></div>hi,<br>
<br>
Concerning the 3D buildings and Street surfaces, I know for sure that<br>
this is data coming from Urbis which is a high quality dataset but even<br>
that doesn't justify importing it into OSM without human review.<br>
<br>
I've been considering to include the Urbis dataset in my tool but I have<br>
to keep the focus on GRB, once that is launched I will point my<br>
attention to Urbis data.  The tool basically does what you state, it<br>
imports it into postgis and makes it easy to export into JOSM directly<br>
and translated to OSM model as good as I/IT can.  The urbis source data<br>
model will work quite well with my transform procedure and tools<br>
<br>
Not all the data there is GIS oriented either.  But a lot is scatttered<br>
around, for example, on the parking subject we are dealing with 12<br>
different datasets, there are sets who represent the access to the<br>
parkings , which in OSM would be a simple access tag on another set. <br>
Here you will have to combine the parking sets and do process the data ,<br>
do the Q/A , handle the exceptions etc.  You cannot consider this job<br>
easy and straightforward, it's going to be painful instead.<br>
<br>
Also, the more I look at the data, the more errors and problems I see, <br>
I've been working with GRB data for a long time and only last week I<br>
contacted Marc to verify if he also noticed that there seems to be an<br>
"addressing" problem in the transformed data where housenumbers seem to<br>
be messed up in certain cases, and he confirmed this.  And that is a<br>
"new" problem, aka: something which slipped my attention for a good year<br>
now...  I traced this down to the .dbf data files containing the address<br>
data, so it's a source problem we need to mitigate. (it's not<br>
impossible, it's just more work)<br>
<br>
That's just to say, preparing this data is so much work, I've been<br>
working on that part alone -daily- for the last 3 months.   It all<br>
starts with quality.  I've been using GRB 3D data set as an aid to<br>
determine building types, that is about as far as I want to go for<br>
several reasons.  the GRB set (non 3D) is a lot better maintained than<br>
3D grb, which kinda looks like an experiment (that went quite well)<br>
<br>
That is also the big issue I have with all the imports in the wild<br>
without data analysis, scrutiny and Q/A work.  We do notice people are<br>
just importing the shape files straight into OSM without understanding<br>
the problems related to this.  Antwerp for example is huge mistake<br>
happening,  Antwerp used to be quite empty on buildings but now it looks<br>
like it's just a flat import of GRB shapefile data (1)<br>
<br>
Also Yves has done his homework on VILLO and STIB data, I've seen what<br>
he had to deal with those datasets, I totally agree with his conclusion<br>
that this isn't just a simple: "hey it's gis data, that's good enough" <br>
and that bulk imports like the one that fucked up Antwerp (but makes it<br>
look good on the map) should be avoided.<br>
<br>
I work at CIBG/CIRB so I can determine the source of certain datasets if<br>
required and talk to people here to get to know where they are coming<br>
from (not all datasets are from government sources, a lot are from<br>
customers of CIBG/CIRB )<br>
<br>
In short, I would be careful and not import in bulk, the schools you<br>
could probably merge/verify with OSM in a few days manually.  I would<br>
choose the latter.  There is more time spent on automating than you(and<br>
definitely me too)  would think at first glance.<br>
<br>
Glenn<br>
<br>
<br>
<br>
[1]   Diff tool : <br>
<a href="http://tiles.grbosm.site/slide/app/index.html#15/51.2091/4.4226" rel="noreferrer" target="_blank">http://tiles.grbosm.site/<wbr>slide/app/index.html#15/51.<wbr>2091/4.4226</a><br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
______________________________<wbr>_________________<br>
Talk-be mailing list<br>
<a href="mailto:Talk-be@openstreetmap.org">Talk-be@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-be" rel="noreferrer" target="_blank">https://lists.openstreetmap.<wbr>org/listinfo/talk-be</a><br>
</div></div></blockquote></div><br></div>