[OSM-dev] OSM export incompatibilities between JOSM and Merkaartor

[Karl Newman]

On Sat, Sep 20, 2008 at 9:10 AM, Chris Browet <cbro at semperpax.com> wrote:

>
>> So let me get this right - when you download data from OSM into
>> Merkaartor, and then make a few edits, you will then have the choice of
>> saving your session "stateful" in a special format, or "stateless" in an
>> format that is almost like OSM XML, just with occasional non-numeric IDs.
>> Correct?
>>
>> So anyone who wants to continue editing in Merkaartor will choose the
>> "stateful" format because it provides much more edit metadata. Correct?
>>
>> The "stateless" format is only there so that the data in the editor can be
>> exported to other applications that expect OSM XML as their input (e.g.
>> scripts, renderers, JOSM, ...) without uploading it first. Correct?
>
>
> Correct on everything.
>
>>
>>
>> Then the fact that JOSM cannot work with these files currently is only a
>> small piece of the problem - neither will, for example, Osmosis, Mapnik, or
>> any of a number of Perl scripts in the repository that assume the object ID
>> to be numeric. (I'm not 100% sure which software actually makes the
>> "numeric" assumption and which doesn't. I believe Osmarender would possibly
>> work with non-numeric IDs also.) - What, then, *is* the current use case for
>> your stateless export format if it cannot be processed by most applications
>> anyway?
>>
>> I don't know. At least one user wanted to import Merkaartor exported OSM
> to JOSM, that's all I care.
>
> Again don't forget that the problem only exists for non-uploaded data. Data
> from the DB is uploaded with a proper OSM ID, so there is no reason not to
> allow it to be exported. Furthermore, Merkaartor allow for different OSM
> layers with data coming from different sources, so there is a valid use case
> in sticking them together in a standard (albeit non JOSM standard) OSM file.
>
> Re your "other apps" argument, I don't quite see what would be the point
> for them to convert xml text attributes to numeric for an ID... If they do,
> well, too bad.
>
> But whatever, forget that I even asked for it.
> I mostly wanted to see if there could be more cooperation on an equal base
> between the 2 projects (and others).
> I guess I have my answer.
>
> Best Regards
> - Chris -
>

Don't take your ball and go home just yet. OSM can be a pretty gruff place,
but I think (I hope!) the developers aren't completely closed-minded.
Frederik was just trying to explain that the format in which JOSM saves its
files is the same format used by many other tools, and is the format
expected by the API when uploading new entities, so it was a natural fit. If
there's a compelling reason to use text-based ID attributes, we'll hear it,
and if it has merit, we can change all the tools to accomodate it.
Otherwise, if your stateless format is primarily used for data exchange with
other tools, why not have it use the format that most tools already expect?

I can answer one reason why some "other apps" convert xml text attributes to
numeric IDs. For Osmosis, anyway, it deals with OSM data in a pipelined or
stream-type fashion, and it uses the IDs sort entities, which is necessary
when it applies changesets. And yes, it could be sorted by a text id as
well...

Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20080920/daa22ef2/attachment.html>