[DotNet-OSGeo] shapefile and such

[Harold Dunsford]

According to http://www.esri.com/library/whitepapers/pdfs/shapefile.pdfthat
the M fields are optional on a shape by shape basis.  So while it is
for sure that there will be X, Y and Z content for every shape, you don't
get a guarantee that there will be M values.  My memory is that we resorted
to testing the shape length from the header to ensure that the data size
was long enough to include M values for the number of points listed.  You
might figure out something else clever.  But your ordering seems correct.

Ted


On Sat, Mar 24, 2012 at 3:37 AM, Carsten Troelsgaard <
carsten at troelsgaard.net> wrote:

> **
>
> Hey all
>
>
>
> Thank you for responding to my question about geographic coordinates. It's
> a part of a continouing quest of accessing shapefiles and paint em' to the
> screen. It's going well, and I'm currently trying out, if my code works as
> it's supposed to. I've been to the osgeo pages with the purpose of
> scrutinizing overall 'standards' that relates to GIS, Geography,
> Projections etc, to conform my work to updated standards. I've shyed away
> though, becourse it appears to be very formal documents that takes an oath
> to download .. never mind, I've probably got something wrong somewhere.
>
> I díd hope, that shapefiles was a solid standard, but I havn't got far
> before meeting one that doesn't execute in my code. It's one that contains
> polygon-z data, and it errs exactly where it reaches the end, had it been
> polygon-m file. I'll set up some error-redirection of the code to conform
> to this particular type of error, but .. how much malformed implementation
> can I expect to meet? se note*
>
>  The .prj file doesn't seem to comply to any standard. Atleast, I've got
> two different types on my  pc . How many different types can I expect?
> I'll be able to handle the two I've met so far, so it's no big deal for
> now.
>
> As for the attribute .dbf file, I did start out with a standard that
> didn't match the first file I tried it on, but it wasn't hard to redo it. I
> look forward to the worst though ...
>
>
>
> Setting out to try to combine the files is somewhat doomed to fail a lot
> on the basis I noted above. I would appreciate any suggestion as to what
> standards to aim at, or comments on what hurdles to expect else
>
>
>
> Kindly Carsten
>
>
>
>  note* the funny thing is, that I exactly knows what goes on in the mind
> of the person that has made the wrong implementation: The order that's in
> your head says x,y (ordinary contents) then x.y.z (conceptual z cont) then
> x,y,z,m ( conceptual  m cont). Esri has it x,y  .. x,y,m  (for m-cont)
> and  x,y,z,m (for z cont).
>
>
> _______________________________________________
> DotNet mailing list
> DotNet at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/dotnet
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/dotnet/attachments/20120326/eb84cd71/attachment.html