Thanks for your responses :)
and yeah i totally agree that an import is probably not a good idea,
but i was thinking more like a map  of missings schools or streets without
surface  (with one in the dataset)
and with ideally a "one-click" import ( 1 feature by 1 feature)

2018-04-04 11:04 GMT+02:00 Glenn Plas <>:

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

Reply via email to