A few notes about file format strategies (with which I am more
familiar than I care to be).
The people consuming your data are going to be be at all kinda of
different levels of experience, using different programming languages
(or not using any at all) on different operating systems, with
different goals in mind.
Given this, the optimum strategy for most situations is to find the
highest resolution/quality version you can, and export that if you can
(which you basically refer to with the comment about asset management
systems).
Once you've made the big high quality export intended for specialised
tools and experts, assume that 80% of people will find that too
complicated.
Now take that main data set, and start culling it down into simpler
datasets, and move towards simpler file formats at the same time.
Examples.
1. Huge asset tracking export, anyone not in the field will need to
spend a month learning from scratch.
2. SQLite export of the main subset of useful data, in a zip file with
an ESRI shapefile holding all the geometry.
3. Simple ESRI and MID/MIF dumps with data only at single table resolution.
4. CSV with the core names, types, descripts, and basic lat/log positions.
Pick a few places in the continuum from CSV to giant industry-specific
program data files that seem useful for your data, and release at
those points.
Then see what feedback you get back over the first few weeks/months,
add new high demand formats, drop the stuff nobody wants (but try to
keep the highest resolution version if only for the principle behind
it).
Adam K
> --
>
> You received this message because you are subscribed to the Google Groups "OpenAustralia Community" group.
> To post to this group, send email to
openaust...@googlegroups.com.
> To unsubscribe from this group, send email to
openaustralia-...@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/openaustralia-dev?hl=.
>
>
>