<div dir="ltr">On Sat, Sep 20, 2008 at 9:10 AM, Chris Browet <span dir="ltr"><<a href="mailto:cbro@semperpax.com">cbro@semperpax.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div dir="ltr"><div class="gmail_quote"><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
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?<br>


<br>
So anyone who wants to continue editing in Merkaartor will choose the "stateful" format because it provides much more edit metadata. Correct?<br>
<br>
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?</blockquote>

</div><div><br>Correct on everything. <br></div><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
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?<div>

<div></div><div><br>
</div></div></blockquote></div><div>I don't know. At least one user wanted to import Merkaartor exported OSM to JOSM, that's all I care.<br><br>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.<br>

<br>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.<br><br>But whatever, forget that I even asked for it. <br>

I mostly wanted to see if there could be more cooperation on an equal base between the 2 projects (and others).<br>I guess I have my answer.<br><br>Best Regards<br>- Chris -<br></div></div></div></blockquote></div><br>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?<br>
<br>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...<br>
<br>Karl<br></div>