[Merkaartor] export to OSM

Matias D'Ambrosio angasule at gmail.com
Fri Dec 5 13:28:46 GMT 2008


On Thursday 04 December 2008 21:19:27 you wrote:
> 2008/12/4 Matias D'Ambrosio <angasule at gmail.com>
>
> >  Currently exporting to OSM seems to be partially broken. It does not
> > work with osm2pgsql (which is needed when using mapnik) because it mixes
> > nodes and
> > ways, so if a way references a node before it is present in the xml, it's
> > not
> > included in the database; I would say this is broken in osm2pgsql
> > (specially
> > the part where no errors are reported!), but it makes sense to place
> > nodes, ways and relations in that order.
>
> Well, it's harsh to say it's broken because it doesn't work with osm2pgsql.
 Well, osm2pgsql is an important use, I'd say! So it's an important usecase.

> As a reminder, downloading OSM from the API doesn't sort the features
> either... It's up to the client to reconcile.
> Furthermore, do not forget that relations can contain relations.
 So, definitely, osm2pgsql has to be worked on.

> if 
> osm2pgsql absolutely need everything is sequence, it will be a PITA to
> generate the OSM it wants.
> Problem with the OSM files is that they are not part of the API, so not
> documented anywhere. There is a common base, which is the returned XML from
> the API. The rest is pretty much clent depended.
 Ah, well, osm2pgsql really needs some work, it seems to have no error 
reporting whatsoever, gave me some headaches when trying to use it at first. 
I had to learn to use psql just to figure out if osm2pgsql was having any 
effect.

> >  From what I have been reading, the functions exportOSM and exportCoreOSM
> > in
> > Map/MapDocument.cpp do most of the work, using Map/MapFeature.* . I
> > haven't spent much time on it but adding a function to MapFeature that
> > returned an enum saying whether it's a node, way or relation would
> > probably be a clean way to later export it in order, or changing
> > exportCoreOSM's return type. exportCoreOSM is currently public, any
> > reason for this? Seems like it belongs
> > in private.
>
> Not need for whatever enum. There is already dynamic_cast,
> MapFeature::getCLass() and QMetaObject::className().
> All you have to do is, in exportOSM(), to put the nodes, ways and relations
> in different QVector rather than a single one.
> Then just "toXML()" them in sequence.
>
 Yes, but it would be a lot easier to place them in separate groups in 
exportCoreOSM (where it checks for type anyway), rather than going through it 
all again.
 It might make sense to have nodes, ways, relations in order for easier 
handling, anyway, even if it's not mandatory.

> >  Another issue is that timestamp and user are not exported by merkaartor,
> > but
> > they seem to be exported by others, any reason not to?
>
> No specific reason. I'll add that.
>
> >  Is relation exporting broken as the code says? I haven't had time to
> > check it.
>
> I don't think so.
 Excellent!




More information about the Merkaartor mailing list