Anneli Gramusset | 2 Aug 21:58 2004
Picon

My problem: Trying to use proj (4.4-8) within a Microsoft Visual C++ 6.0 project: It doesn´t work.

Hello.
 
I have already written, but I wasn´t in the group. So I don´t know if you got my message. I´ll explain my problem again. I would like to use the proj library (release 4.4.8) within a Visual C++ project. I have followed all instructions to install it and I´ve tried to compile/execute an exemple taken from the manual "Cartographic Projection Procedures, Release 4, Interim Report" by Gerald I. Evenden.
 
After making some changes (projUV instead of UV...) I could compile the exemple1.c...
But the linking doen´t work. I get the following error messages:
 
                    example1.obj : error LNK2001: unresolved external symbol _pj_fwd
                    example.obj : error LNK2001: unresolved external symbol _pj_init
                    Debug/ejemplo1.exe : fatal error LNK1120: 2 unresolved externals
                    Error executing link.exe.
                    Creating browse info file...
                   
                    example1.exe - 3 error(s), 0 warning(s)
 
I really don´t understand what´s happening. If someone has already work with Microsoft Visual C++ (I don´t have the choice, sorry) and can help me, I´ll be very greatful.
 
Thank you,
 
Anneli Gramusset

_______________________________________________
Proj mailing list
Proj <at> xserve.flids.com
http://xserve.flids.com/mailman/listinfo/proj
Sam Harrell | 2 Aug 23:25 2004

RE: [myjunk] [Proj] My problem: Trying to use proj (4.4-8) within a Microsoft Visual C++ 6.0 project: It doesn´t work.

3 critical project settings

 

  1. Linker -> General -> Additional Library directories (point to proj.lib)

  2. Linker -> Input -> Additional Dependencies (must include proj.lib)

  3. C++ settings -> Additional include directories ( point to source files)

 

If you get more LNK errors, you may need to set some other flags.

  1. C++ -> Code generation -> RunTime library (set to Mtd)

  2. Linker -> Input -> Additional Dependencies (may need to add nochkclr.obj mscoree.lib)

 

 

Hope this helps,

Sam

 

 

 

From: proj-bounces <at> xserve.flids.com [mailto:proj-bounces <at> xserve.flids.com] On Behalf Of Anneli Gramusset
Sent: Monday, August 02, 2004 3:58 PM
To: proj <at> xserve.flids.com
Subject: [myjunk] [Proj] My problem: Trying to use proj (4.4-8) within a Microsoft Visual C++ 6.0 project: It doesn´t work.

 

Hello.

 

I have already written, but I wasn´t in the group. So I don´t know if you got my message. I´ll explain my problem again. I would like to use the proj library (release 4.4.8) within a Visual C++ project. I have followed all instructions to install it and I´ve tried to compile/execute an exemple taken from the manual "Cartographic Projection Procedures, Release 4, Interim Report" by Gerald I. Evenden.

 

After making some changes (projUV instead of UV...) I could compile the exemple1.c...

But the linking doen´t work. I get the following error messages:

 

                    example1.obj : error LNK2001: unresolved external symbol _pj_fwd
                    example.obj : error LNK2001: unresolved external symbol _pj_init
                    Debug/ejemplo1.exe : fatal error LNK1120: 2 unresolved externals
                    Error executing link.exe.
                    Creating browse info file...

                   

                    example1.exe - 3 error(s), 0 warning(s)

 

I really don´t understand what´s happening. If someone has already work with Microsoft Visual C++ (I don´t have the choice, sorry) and can help me, I´ll be very greatful.

 

Thank you,

 

Anneli Gramusset

 

_______________________________________________
Proj mailing list
Proj <at> xserve.flids.com
http://xserve.flids.com/mailman/listinfo/proj
Daniel Morissette | 5 Aug 18:26 2004
Picon

PROJ4: epsg:4135 broken?

Frank,

I was going to submit this in the PROJ bugzilla, but it is currently
unavailable, so I decided to send to the list instead.

We have been trying to display GPS points (WGS84, EPSG:4326) over the
Hawaii TIGER data which is in the "Old Hawaiian" datum. The epsg file
that comes with PROJ contains code 4135 which is labelled as Old
Hawaiian, but the definition doesn't contain any datum information.

We tried to go from 4326 to 4135 but nothing happens. After a bit of
digging and research, we found some datum shift parameters for Old
Hawaiian, and I came up with the following definition which seems to
work for our data:

   +proj=longlat +ellps=clrk66 +towgs84=61,-285,-181,0,0,0,0

Is this the best we can do or is there a way we could use the "hawaii"
file that's in the proj directory? Should the epsg file be updated with
this fix?

Thanks

Daniel
--

-- 
------------------------------------------------------------
  Daniel Morissette               dmorissette <at> dmsolutions.ca
  DM Solutions Group              http://www.dmsolutions.ca/
------------------------------------------------------------

_______________________________________________
Proj mailing list
Proj <at> xserve.flids.com
http://xserve.flids.com/mailman/listinfo/proj

VAN DAELE, Toon | 6 Aug 11:37 2004
Picon

towgs84 - problem with datum rotation parameters

Hi all,

For the transformation of WGS84 to BD72 (belgian datum), I'm using
towgs84 with the 7 parameter transformation. The published parameters
are (national geographical institute, NGI):

dX=-99.059, dY=53.322, dZ=-112.486, rX=-.419, rY=.83, rZ=-1.885,
ds=0.99999

With these parameters the result are about 70 meters away from the
locations I got with the transformation tool from the NGI. After a few
hours of trying I found out the calculation is perfect (differences less
than a centimeter) when only the sings of the rotation parameters are
changed, thus:

dX=-99.059, dY=53.322, dZ=-112.486, rX=.419, rY=-.83, rZ=1.885,
ds=0.99999

I've checked this with several widely spread control points, and it's
perfect. Is there an explanation why the rotation parameters could be
defined in the opposite direction? Have other people experienced the
same problem with the 7 parameter transformation?

Regards,
Toon

---------------------------------
Toon Van Daele
Instituut voor Natuurbehoud
Kliniekstraat 25, 1070 Brussel
Tel: 02 558 18 10
Fax: 02 558 18 05
GSM: 0498 05 68 90
toon.van.daele <at> instnat.be
http://www.nara.be
---------------------------------
_______________________________________________
Proj mailing list
Proj <at> xserve.flids.com
http://xserve.flids.com/mailman/listinfo/proj

Paul Kelly | 6 Aug 12:57 2004
Picon

Re: towgs84 - problem with datum rotation parameters

On Fri, 6 Aug 2004, VAN DAELE, Toon wrote:

> Hi all,
>
> For the transformation of WGS84 to BD72 (belgian datum), I'm using
> towgs84 with the 7 parameter transformation. The published parameters
> are (national geographical institute, NGI):
>
> dX=-99.059, dY=53.322, dZ=-112.486, rX=-.419, rY=.83, rZ=-1.885,
> ds=0.99999
>
> With these parameters the result are about 70 meters away from the
> locations I got with the transformation tool from the NGI. After a few
> hours of trying I found out the calculation is perfect (differences less
> than a centimeter) when only the sings of the rotation parameters are
> changed, thus:
>
> dX=-99.059, dY=53.322, dZ=-112.486, rX=.419, rY=-.83, rZ=1.885,
> ds=0.99999
>
> I've checked this with several widely spread control points, and it's
> perfect. Is there an explanation why the rotation parameters could be
> defined in the opposite direction? Have other people experienced the
> same problem with the 7 parameter transformation?

Yes the two different rotation direction conventions is a common and 
well-documented problem. The CRS website is a good reliable source:
http://crs.bkg.bund.de/crseu/crs/descr/eu-countrysel.php?country=BE
gives the parameters as in your second example except that the sign of the 
scale (the last parameter) is reversed, i.e. -1. Does this make any 
difference?

The parameters used in GRASS
http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/grass/src/libes/gis/datumtransform.table
for the bel72 datum are the same as those on the CRS website, but if you 
can confirm that it still works with the scale factor sign change then I 
will update the parameters in the GRASS datum list to the more precise 
values you have given.

Paul Kelly

_______________________________________________
Proj mailing list
Proj <at> xserve.flids.com
http://xserve.flids.com/mailman/listinfo/proj

Frank Warmerdam | 11 Aug 15:24 2004
Picon

Bugzilla working again.

Folks,

I justed wanted to let you know that the bugzilla.remotesensing.org is working
again (pointing to the old instance hosted at imagelinks.com) so PROJ.4, libtiff,
libgeotiff and GDAL bug handling should be returning to normal.

I would also mention that I have had severe email problems the last couple weeks
so if you sent me email and were hoping for a response it is *possible* I
didn't get your email.  Of course, I might just be ignoring you ...

Best regards,
--

-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam <at> pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

_______________________________________________
Proj mailing list
Proj <at> xserve.flids.com
http://xserve.flids.com/mailman/listinfo/proj

Dylan Keon | 17 Aug 18:47 2004

trouble using Michigan GeoRef projection

Hello,

I posted this question to mapserver-users and Frank W. replied, 
suggesting that I try this mailing list.  My original question and 
Frank's reply are copied below.  Thanks for any assistance.

--Dylan

>> Hi,
>> 
>> I'm trying to use a layer that's projected in the "Michigan GeoRef"
>> projection, but I can't get it to line up with other data.  I'm using
>> the projection parameters provided by the state of Michigan
>> (http://www.michigan.gov/documents/DNR_Map_Proj_and_MI_Georef_Info_20889_7.pdf).
>> 
>> Here's what I get when trying to line up a Michigan layer (GeoRef
>> projection) with a national 24k quad index (geographic), putting
>> everything into geographic for now:
>> 
>>    http://gis.nacse.org/mstemp/109267161738211.png
>> 
>> I haven't found examples of this online, and wonder if I messed up a
>> PROJ definition or something.  Thanks for any help.  Mapfile is below.
>> 
>> --Dylan
>> 
>> 
>> NAME 'test'
>> SIZE 640 480
>> STATUS ON
>> EXTENT -126 34 -66 46
>> UNITS DD
>> 
>> IMAGETYPE png
>> 
>> WEB
>>   IMAGEPATH '/www/temp/'
>>   IMAGEURL '/temp/'
>> END
>> 
>> PROJECTION
>>   'init=epsg:4326' #latlon
>> END
>> 
>> LAYER
>>   NAME 'quad_index'
>>   DATA '/gis/data/us/24kgrid.shp'
>>   STATUS DEFAULT
>>   TYPE POLYGON
>>   CLASS
>>     COLOR -1 -1 -1
>>     OUTLINECOLOR 0 0 255
>>   END
>>  PROJECTION
>>     'init=epsg:4326' #latlon
>>   END
>> END
>> 
>> LAYER
>>   NAME 'ecoregions'
>>   DATA '/gis/data/mi/ecoreg100'
>>   STATUS DEFAULT
>>   TYPE POLYGON
>>   CLASS #simple for now
>>     COLOR 198 123 48
>>   END
>>   PROJECTION #NAD 1983 Michigan GeoRef Meters <102123>
>>     'proj=omerc'
>>     'k_0=0.9996'
>>     'lat_0=45.30916666666666'
>>     'alpha=337.255555555556'
>>     'lonc=-86'
>>     #'x_0=2546731.496'    # PROJ
>>     #'y_0=-4354009.816'   # manual
>>     #'ellps=GRS80'        # says these are not
>>     #'datum=NAD83'        # needed for oblique mercator,
>>     #'units=m'            # but I tried them too,
>>     #'no_defs'            # in various combinations
>>   END
>> END
>> 
>> END
>>

> Dylan,
> 
> Hmm, I made an effort but couldn't get this to work.  I would suggest you
> take your question to the PROJ.4 mailing list.  I would also include that
> ESRI defines this projection as:
> 
> PROJCS["NAD_1983_Michigan_GeoRef_Meters",
>     GEOGCS["GCS_North_American_1983",
>         DATUM["D_North_American_1983",
>             SPHEROID["GRS_1980",6378137,298.257222101]],
>         PRIMEM["Greenwich",0],
>         UNIT["Degree",0.017453292519943295]],
>     PROJECTION["Hotine_Oblique_Mercator_Azimuth_Natural_Origin"],
>     PARAMETER["False_Easting",2546731.496],
>     PARAMETER["False_Northing",-4354009.816],
>     PARAMETER["Scale_Factor",0.9996],
>     PARAMETER["Azimuth",337.255555555556],
>     PARAMETER["Longitude_Of_Center",-86],
>     PARAMETER["Latitude_Of_Center",45.30916666666666],
>     UNIT["Meter",1]]
> 
> And stress lat/long value provided for the GeoRef projection origin in the
> .pdf file referenced.  While a test point at the origin is the worst kind of
> test point for a projection, it is something to work with.  I couldn't even
> get it to work out properly.
> 
> Hopefully Gerald Evenden will know whats up.
> 
> Best regards,
> -- 
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam <at> pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | Geospatial Programmer for Rent 

_______________________________________________
Proj mailing list
Proj <at> xserve.flids.com
http://xserve.flids.com/mailman/listinfo/proj

Naiara S. Pinto | 18 Aug 21:25 2004
Picon

latlong to latlong conversion

Hi folks,

I am new to proj and I am trying to convert a file that is in
latlong(spheroid based, GRS80) into another latlong (datum based, WGS84).
Is that possible?
Any tips would be greatly appreciated!

Thanks,

Naiara.
_______________________________________________
Proj mailing list
Proj <at> xserve.flids.com
http://xserve.flids.com/mailman/listinfo/proj

Frank Warmerdam | 18 Aug 21:41 2004
Picon

Re: latlong to latlong conversion

Naiara S. Pinto wrote:
> Hi folks,
> 
> I am new to proj and I am trying to convert a file that is in
> latlong(spheroid based, GRS80) into another latlong (datum based, WGS84).
> Is that possible?
> Any tips would be greatly appreciated!

Naiara,

This can be accomplished with the cs2cs tool which handles a "coordinate system
to coordinate system" conversion.

For example, to convert from lat/long NAD27 to lat/long WGS84 you might do:

   cs2cs +proj=latlong +datum=NAD27 +to +proj=latlong +datum=WGS84
   ...

Note that the GRS80 and WGS84 ellipsoids are not very different and a
conversion between them without any extra datum shift information provided
will not generally result in any perceptible change.

Also, the above command is essentially for conversion of a list of x,y
pairs.  If you have a vector file or raster file, additional issues
apply, and you will need to be more specific.

Best regards,
--

-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam <at> pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

_______________________________________________
Proj mailing list
Proj <at> xserve.flids.com
http://xserve.flids.com/mailman/listinfo/proj

Melita Kennedy | 19 Aug 08:04 2004
Picon

Re: Proj Digest, Vol 3, Issue 4

Dylan,

I can explain why the origin point doesn't give the expected values.
Michigan GeoRef (and State Plane's Alaska zone 1) use what ESRI 
calls Oblique Mercator Natural Origin. The xy 0,0 location is where
the central line crosses the aposphere's equator rather than the
intersection of the longitude and latitude of center. The origin is 
usually quite close to the ellipsoid's equator. That's why the false 
easting and northing values are so large.

Melita

-- 
Melita Kennedy
mkennedy <at> pe.net

> Date: Tue, 17 Aug 2004 09:47:19 -0700
> From: Dylan Keon <keon <at> nacse.org>
> Subject: [Proj] trouble using Michigan GeoRef projection
> To: proj <at> xserve.flids.com
> 
> Hello,
> 
> I posted this question to mapserver-users and Frank W. replied,
> suggesting that I try this mailing list.  My original question and
> Frank's reply are copied below.  Thanks for any assistance.
> 
> --Dylan
> 
> >> Hi,
> >>
> >> I'm trying to use a layer that's projected in the "Michigan GeoRef"
> >> projection, but I can't get it to line up with other data.  I'm using
> >> the projection parameters provided by the state of Michigan
> >> (http://www.michigan.gov/documents/DNR_Map_Proj_and_MI_Georef_Info_20889_7.pdf).
> >>
> >> Here's what I get when trying to line up a Michigan layer (GeoRef
> >> projection) with a national 24k quad index (geographic), putting
> >> everything into geographic for now:
> >>
> >>    http://gis.nacse.org/mstemp/109267161738211.png
> >>
> >> I haven't found examples of this online, and wonder if I messed up a
> >> PROJ definition or something.  Thanks for any help.  Mapfile is below.
> >>
> >> --Dylan
> >>
> >>
> >> NAME 'test'
> >> SIZE 640 480
> >> STATUS ON
> >> EXTENT -126 34 -66 46
> >> UNITS DD
> >>
> >> IMAGETYPE png
> >>
> >> WEB
> >>   IMAGEPATH '/www/temp/'
> >>   IMAGEURL '/temp/'
> >> END
> >>
> >> PROJECTION
> >>   'init=epsg:4326' #latlon
> >> END
> >>
> >> LAYER
> >>   NAME 'quad_index'
> >>   DATA '/gis/data/us/24kgrid.shp'
> >>   STATUS DEFAULT
> >>   TYPE POLYGON
> >>   CLASS
> >>     COLOR -1 -1 -1
> >>     OUTLINECOLOR 0 0 255
> >>   END
> >>  PROJECTION
> >>     'init=epsg:4326' #latlon
> >>   END
> >> END
> >>
> >> LAYER
> >>   NAME 'ecoregions'
> >>   DATA '/gis/data/mi/ecoreg100'
> >>   STATUS DEFAULT
> >>   TYPE POLYGON
> >>   CLASS #simple for now
> >>     COLOR 198 123 48
> >>   END
> >>   PROJECTION #NAD 1983 Michigan GeoRef Meters <102123>
> >>     'proj=omerc'
> >>     'k_0=0.9996'
> >>     'lat_0=45.30916666666666'
> >>     'alpha=337.255555555556'
> >>     'lonc=-86'
> >>     #'x_0=2546731.496'    # PROJ
> >>     #'y_0=-4354009.816'   # manual
> >>     #'ellps=GRS80'        # says these are not
> >>     #'datum=NAD83'        # needed for oblique mercator,
> >>     #'units=m'            # but I tried them too,
> >>     #'no_defs'            # in various combinations
> >>   END
> >> END
> >>
> >> END
> >>
> 
> > Dylan,
> >
> > Hmm, I made an effort but couldn't get this to work.  I would suggest you
> > take your question to the PROJ.4 mailing list.  I would also include that
> > ESRI defines this projection as:
> >
> > PROJCS["NAD_1983_Michigan_GeoRef_Meters",
> >     GEOGCS["GCS_North_American_1983",
> >         DATUM["D_North_American_1983",
> >             SPHEROID["GRS_1980",6378137,298.257222101]],
> >         PRIMEM["Greenwich",0],
> >         UNIT["Degree",0.017453292519943295]],
> >     PROJECTION["Hotine_Oblique_Mercator_Azimuth_Natural_Origin"],
> >     PARAMETER["False_Easting",2546731.496],
> >     PARAMETER["False_Northing",-4354009.816],
> >     PARAMETER["Scale_Factor",0.9996],
> >     PARAMETER["Azimuth",337.255555555556],
> >     PARAMETER["Longitude_Of_Center",-86],
> >     PARAMETER["Latitude_Of_Center",45.30916666666666],
> >     UNIT["Meter",1]]
> >
> > And stress lat/long value provided for the GeoRef projection origin in the
> > .pdf file referenced.  While a test point at the origin is the worst kind of
> > test point for a projection, it is something to work with.  I couldn't even
> > get it to work out properly.
> >
> > Hopefully Gerald Evenden will know whats up.
> >
> > Best regards,
> > --
_______________________________________________
Proj mailing list
Proj <at> xserve.flids.com
http://xserve.flids.com/mailman/listinfo/proj


Gmane