2008/8/8 Marcus Wolschon <[EMAIL PROTECTED]>: > > > On Fri, 8 Aug 2008 13:30:17 +0200, "Nic Roets" <[EMAIL PROTECTED]> wrote: >>> Does mmapping data-structures with links work when the file comes >>> from another device where memory-locations may be different? >> >> The file contains indexes. Converting it to pointers does not take >> many CPU cycles. > > Okay. Thank you for the answer. I was not sure about that point. > > >>>> * Windows (incl WinCE) comes with fast rendering of rotated text. Can >>>> other mobile platforms do it fast enough ? I find cairo a bit sluggish >>>> on my notebook, perhaps it's really bad on OpenMoko... >>> >>> I don't think this affects the data-format at all. >> >> If we know what software we're going to support, we will have a better >> idea what hardware we're going to support. Then we will know what the >> space and performance issues are going to be. > > Okay. > My choice of sensible platforms would be: > > Windows Mobile 6.1 C# > Linux (ARMv4l) gcc-native > Linux (ARMv4l) blacksdown-JDK > Linux (ARMv4l) IBM J9 > Windows Mobile 5.0 C# > Windows Mobile 5.0 C++ > > Who wants to add some?
Windows Mobile 2003 is still much used >>> Yes, mobile editing is usefull. Do you suggest to not limit the format? >> >> No. Mobile editors should duplicated any nodes used. Those nodes >> should be merged with the existing / real node to during >> postprocessing when appropriate. Same goes for ways. > > So you suggest that a data-format MUST contain nodes, node/way-ids, > their timestamps and all tags of all nodes and ways? > Else it would not be possible to reconstruct the original node/way > for uploading after editing. i think we should not want a special fileformat for editors, they want all the info, so better use the osm files for this, or let them download live data over the air by a (bin/zip) protocol (i was working on a windows mobile editor and never thought about a special binary fileformat, the working area of a editor is small enough to store/load into ram) >>> Do you have further arguments supporting the point I think you wanted to >>> make? >> >> There are so many : >> 1. Agreeing on APIs (function prototypes) are better than agreeing on >> data structures. >> 2. Simplify, simplify, simplify. > > I disagree here. > We already have an API that everyone is using and that seems to be good. > However a common data-format provides interoperability, better tool-support > (converters), eases debugging a great deal and can always be a starting-point > for individual formats. > A starting-point that has already condensed all of our best ideas > and experiences on the topic instead of just a single developers ideas. > > Marcus _______________________________________________ Routing mailing list Routing@openstreetmap.org http://lists.openstreetmap.org/listinfo/routing
