[Mapserver-users] Projection woes, Revisited.
Ed McNierney
ed at topozone.com
Tue Feb 4 16:32:51 EST 2003
Chip -
OK - I can run your final example and get the right answer. That is, I get a green box with a red border neatly placed around it.
Now, I can say very little about your 3.6.3 build, since I don't know the details of how it was built. I can provide you with the 3.7 build I am using for testing, which would at least let you determine whether it's a PROJ data file setup issue or a MapServer code issue.
- Ed
-----Original Message-----
From: Hankley, Chip [mailto:Chip.Hankley at GASAI.Com]
Sent: Tuesday, February 04, 2003 4:11 PM
To: Ed McNierney; MapServer List (E-mail)
Subject: RE: [Mapserver-users] Projection woes, Revisited.
It's in there. It's called box_sps83m.*
Thanks again...
Chip
> -----Original Message-----
> From: Ed McNierney [mailto:ed at topozone.com]
> Sent: Tuesday, February 04, 2003 2:02 PM
> To: Hankley, Chip; MapServer List (E-mail)
> Subject: RE: [Mapserver-users] Projection woes, Revisited.
>
>
> Chip -
>
> Thanks - one more request - could you update the ZIP file
> with the new shapefile?
>
> - Ed
>
> -----Original Message-----
> From: Hankley, Chip [mailto:Chip.Hankley at GASAI.Com]
> Sent: Tuesday, February 04, 2003 2:52 PM
> To: Ed McNierney; MapServer List (E-mail)
> Subject: RE: [Mapserver-users] Projection woes, Revisited.
>
>
> OK,
>
> I've added another demo onto the page:
>
> http://207.250.243.23/projtest/projtest.html
>
> This last one has only the two 'boxes', and the output
> projection is WI
> State Plane South, NAD83, meters (epsg:32154). Note that this
> necessitated
> me creating a new data set, since my other SPS83 box was
> FEET. The epsg code
> assumes the data is meters.
>
> I also changed the NAD27 box to be transparent with a red
> outline for the
> last two examples (just to show for sure that it is not reprojecting).
>
> Also, just in case anyone was wondering... those are in-line
> images being
> created on the fly using MS (look at the source) so.. you are
> seeing the
> real deal - i.e. I'm not making this up ;)
>
> Thanks for the interest and help!
>
> Chip
>
> > -----Original Message-----
> > From: Ed McNierney [mailto:ed at topozone.com]
> > Sent: Tuesday, February 04, 2003 1:07 PM
> > To: Hankley, Chip; MapServer List (E-mail)
> > Subject: RE: [Mapserver-users] Projection woes, Revisited.
> >
> >
> > Chip -
> >
> > Thanks for posting all the data and samples. I think it
> > might be helpful to simplify things a bit.
> >
> > Here's what I see. You have two boxes, of the same extents,
> > one in Wisconsin South NAD27 Feet, the other in Wisconsin
> > South NAD83 Feet (both LCC projections). Let's ignore
> > everything else and try to get those two to overlap.
> >
> > First, you might want to use the EPSG codes for these
> > projections. They're more obtuse, but they protect against
> > typos when spelling out all the projection parameters.
> >
> > For Wisconsin State Plane South NAD27, the code is 32054, and
> > for NAD83 it's 32154. So each of your projection blocks can become:
> >
> > # NAD27
> >
> > PROJECTION
> > "init=epsg:32054"
> > END
> >
> > # NAD83
> >
> > PROJECTION
> > "init=epsg:32154"
> > END
> >
> > This is similar to your last example. In looking at your
> > last example, however, one wonders whether the NAD83 box is
> > right there UNDERNEATH the red NAD27 box - if it were
> > projecting properly, how could you tell?
> >
> > Can you set up another example that does the following:
> >
> > 1. Uses the EPSG codes for projections
> > 2. Defines the output projection to be Wisconsin State Plane
> > South NAD83
> > 3. Defines only two input layers
> > 4. Makes the OUTLINECOLOR for the NAD27 box be "255 0 0"
> > (red) and removes the COLOR statement, so it's hollow?
> >
> > Then let us take a look. Thanks!
> >
> > - Ed
> >
> >
> > -----Original Message-----
> > From: Hankley, Chip [mailto:Chip.Hankley at GASAI.Com]
> > Sent: Tuesday, February 04, 2003 1:18 PM
> > To: Ed McNierney; MapServer List (E-mail)
> > Subject: RE: [Mapserver-users] Projection woes, Revisited.
> >
> >
> > Ed (and everyone) -
> >
> > OK... showing my ignorance here. I ALWAYS use pre-compiled
> > binaries (I'm
> > trying to overcome this personal defect...). Anyway, I'm only
> > beginning to
> > understand the compilation sequence, and how all the parts
> > fits together...
> > so, patience please!
> >
> > When I download the binaries from the Mapserver site, the
> > only PROJ related
> > file that comes with the distribution is the epsg file. I
> have this in
> > C:\PROJ\NAD.
> >
> > I did download the datum shift files (from remotesensing.org)
> > and simply put
> > them in the NAD subdirectory, but this doesn't seem to make
> > any difference
> > (not suprisingly). I'm assuming that when you say that I
> > "need to have these
> > datum shift files set up and PROJ pointed to them in order to
> > do the shift"
> > that this is an operation that would occur when compiling the
> > PROJ4 library
> > prior to compiling MapServer? Have I got that sequence right?
> >
> > If this is right, why don't the pre-compiled binaries that
> > exist already do
> > this (just curious)? Seems like datum shifts would be a
> fairly common
> > task...
> >
> > Chip
> >
> >
> >
> > > -----Original Message-----
> > > From: Ed McNierney [mailto:ed at topozone.com]
> > > Sent: Tuesday, February 04, 2003 11:36 AM
> > > To: Hankley, Chip; MapServer List (E-mail)
> > > Subject: RE: [Mapserver-users] Projection woes, Revisited.
> > >
> > >
> > > Chip -
> > >
> > > The PROJ4 FAQ refers to the work you need to do to have the
> > > NAD datum shift files built - the code doesn't change. Do
> > > you have your PROJ installation in C:\PROJ? Whereever it is,
> > > look in that directory for a NAD subdirectory and files named
> > > CONUS, NAD27, NAD83, ALASKA, etc. (no file extensions). You
> > > need to have these datum shift files set up and PROJ pointed
> > > to them in order to do the shift.
> > >
> > > - Ed
> > >
> > > Ed McNierney
> > > President and Chief Mapmaker
> > > TopoZone.com / Maps a la carte, Inc.
> > > 73 Princeton Street, Suite 305
> > > North Chelmsford, MA 01863
> > > ed at topozone.com
> > > (978) 251-4242
> > >
> > >
> > > -----Original Message-----
> > > From: Hankley, Chip [mailto:Chip.Hankley at gasai.com]
> > > Sent: Tuesday, February 04, 2003 12:17 PM
> > > To: MapServer List (E-mail)
> > > Subject: [Mapserver-users] Projection woes, Revisited.
> > >
> > >
> > > OK, I'm still unable to do a datum shift between NAD27 and NAD83.
> > >
> > > I've tried to strip out all of the non-essentials and come
> > up with an
> > > example. You can view it on-line at:
> > >
> > > http://207.250.243.23/projtest/projtest.html
> > >
> > > Basically, I can reproject data FINE when it's in the same
> > > datum. It's when
> > > I try to do a datum shift that things don't work. I'm using
> > one of the
> > > pre-compiled binaries from the MS site. Here's my version info:
> > >
> > > MapServer version 3.6.3 OUTPUT=PNG OUTPUT=JPEG OUTPUT=WBMP
> > > SUPPORTS=PROJ
> > > SUPPORTS=TTF SUPPORTS=WMS_SERVER SUPPORTS=WMS_CLIENT
> > > INPUT=TIFF INPUT=EPPL7
> > > INPUT=JPEG INPUT=OGR INPUT=SHAPEFILE
> > >
> > > Could the problem be with the way PROJ4 was compiled into
> > > this binary? The
> > > PROJ4 FAQ has some specific instructions for building PROJ4
> > > to support datum
> > > shifts... (see http://www.remotesensing.org/proj/faq.html). I
> > > don't know how
> > > to check this on the binary...
> > >
> > > TIA!
> > >
> > > Chip
> > > _______________________________________________
> > > Mapserver-users mailing list
> > > Mapserver-users at lists.gis.umn.edu
> > > http://lists.gis.umn.edu/mailman/listinfo/mapserver-users
> > >
> >
>
More information about the mapserver-users
mailing list