<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;">

<br>Initial thoughts from my end (as main developer of Osmosis) is that it would be best to keep it separate until you've let it evolve somewhat.  If you can develop it as a plugin for now it will let us (ie. Osmosis core, and osmosis bin format) remain independent until it matures and stabilises.  If it has a wide enough audience (ie. useful to more than a small handful of people) then we can look at incorporating it into the core of Osmosis.  At that point it will need to meet the current Osmosis code quality checks (eg. checkstyle), have unit tests, and pass a code review.  None of that is too difficult, but I need to ensure it doesn't add a maintenance burden.<br>



<br></blockquote><div><br>I agree wholeheartedly with letting it evolve and I'm interested in hearing yours (and others) thoughts on what additional features to include or exclude.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">


I can possibly help with some ant and ivy advice in terms of how to incorporate it with Osmosis.  It should be possible to make the existing osmosis library an Ivy dependency of your library.  It might make sense to split your library in two parts, the generic re-usable code, and the Osmosis specific tasks.  But I'm only speculating until I understand what you've done.<br>



<br></blockquote><div><br>Thanks, I'd appreciate that advice. The code is already segregated into osmosis independent and osmosis dependent packages; the independent code is already reused in my patches to the mkgmap splitter to read the binary files.<br>


 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Longer term I'm open to suggestions on how Osmosis should incorporate new features like this.  It may actually make more sense to pull some existing features out of Osmosis and make them plugins also, or it may be simpler to just keep adding to the core.  But these questions are more suited to the osmosis-dev list.<br>


<font color="#888888">
<br></font></blockquote><div><br>You've got a nice architecture; it was very easy to figure out how to get my code to tie-in to your design, at least as a built in. Making it work as a plugin will be more effort.<br>

<br>My biggest wish is that there should be a common library used by the different OSM software for representing lowlevel concepts such as points, bounding boxes, entities, etc, or at least define an baseline interface that the different OSM software offers  for accessing their different entity implementations. I could target that. mkgmap, osmosis, the splitter, and josm all have 'Node' and 'Way'
defined in semantically identical fashions, yet are incompatible types.
To support all 4 of them requires reimplementing the binary serializer
and deserializer 4 times, quadrupling the chances of having a bug. Such an interface would make it possible to have a shared XML-entity parser/writer implementation and make code more reusable across these
applications. For instance, I'm interested in reusing josm's quadtree
implementation in osmosis. I have a local patch that refactors it to support anything that has a getBBox() and isUsable() functions, but using it requires importing josm's notion of bounding boxes and coordinates into osmosis along with refactoring out dependencies on  java.awt.geom.Rectangle2D, and org.openstreetmap.josm.Main (via LatLon).<br>

<br>Scott<br><br>

</div></div>