headers
Glynn Clements | 1 Aug 2010 17:30

Re: quoting +nadgrids ?


Frank Warmerdam wrote:

> Based on this, I'm starting to think that the PROJ.4
> parameter parser just ought to have a special escape
> sequence for embedding a space.  Ideally something not
> likely to "activate" other escape sequence parsers.
> Something like:
> 
> +nadgrids=C:\Program <at>  <at>  <at> space <at>  <at>  <at> Files\GRASS...
> 
> If you would like me to incorporate such a change, let me know
> via a proj.4 ticket and I'll proceed.

Personally, I'm not inclined to suggest that PROJ should be
introducing this sort of workaround for issues with software which
uses it.

However, if you decide to go that route, URL encoding (%##, e.g. %20
for space) serves roughly this purpose (although the use of '+' for
space wouldn't be desirable here). This assumes that % is uncommon in
PROJ parameter values.

Another option would be to provide utility functions to convert
between an argument list (i.e. a list of strings) and a string. This
would make it easier for GDAL (etc) to "do it right".

The two options aren't mutually exclusive, although the latter would
eliminate the need to perform encoding/decoding of arguments when
invoking proj or cs2cs directly.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Frank Warmerdam | 1 Aug 2010 18:03
Picon
Favicon
Gravatar

Re: quoting +nadgrids ?

Glynn Clements wrote:
> Personally, I'm not inclined to suggest that PROJ should be
> introducing this sort of workaround for issues with software which
> uses it.
> 
> However, if you decide to go that route, URL encoding (%##, e.g. %20
> for space) serves roughly this purpose (although the use of '+' for
> space wouldn't be desirable here). This assumes that % is uncommon in
> PROJ parameter values.

Glynn,

I had been avoiding "normal" escaping schemes primarily to avoid
the escaping getting interpreted earlier in the processing chain,
though I suppose url encoding would not be widely used.  Also, to
the best of my knowledge the only things we might need to escape
would be " " and "+".

> Another option would be to provide utility functions to convert
> between an argument list (i.e. a list of strings) and a string. This
> would make it easier for GDAL (etc) to "do it right".

In fact GDAL uses pj_init_plus() which takes the whole string rather
than a set of pre-separated options.  So PROJ.4 already does have
a natural place to put the parsing rules for applications that use it.

Earlier I suggested this issue wasn't really a PROJ.4 issue, but now
that I think about pj_init_plus() it clearly is a PROJ.4 issue.  Based
on that it seems to come down to how to do the escaping for interpretation
by pj_init_plus().
(Continue reading)

Permalink | Reply | 7 comments |
headers
Paul Kelly | 1 Aug 2010 19:30
Picon

Re: quoting +nadgrids ?

On Sun, 1 Aug 2010, Frank Warmerdam wrote:

> In fact GDAL uses pj_init_plus() which takes the whole string rather
> than a set of pre-separated options.  So PROJ.4 already does have
> a natural place to put the parsing rules for applications that use it.
>
> Earlier I suggested this issue wasn't really a PROJ.4 issue, but now
> that I think about pj_init_plus() it clearly is a PROJ.4 issue.  Based
> on that it seems to come down to how to do the escaping for interpretation
> by pj_init_plus().

Hi Frank,
I have no specific comments on how the escaping it should be done, just 
that it would be great if pj_get_def() can add escaping using whatever 
method is decided, as well as pj_init_plus() interpreting it. That is, it 
should be possible for an application to generate a PROJ string with 
pj_get_def() and pass it to another application unmodified, which then 
processes it using pj_init_plus(), and all the escaping would pass through 
intact.

Paul
_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
Permalink | Reply | 0 comments |
headers
Glynn Clements | 1 Aug 2010 20:04

Re: quoting +nadgrids ?


Frank Warmerdam wrote:

> I had proposed the  <at>  <at>  <at> space <at>  <at>  <at>  idea just because it wouldn't be interpreted
> anywhere else, though it is somewhat peculiar.  Can you, or anyone,
> provide an argument for a different approach?  Were you suggesting url
> encoding because it was easily extended to other escaping operations?

Mostly because it's already known, can be used to escape arbitrary
characters, the % sign seems (to me) unlikely to occur in an argument,
and the worst case for the size of an escaped string isn't too bad
(three times the size of the original string).

[Needless to say, the first question which crossed my mind regarding
the  <at>  <at>  <at> space <at>  <at>  <at>  idea was: what happens if the text " <at>  <at>  <at> space <at>  <at>  <at> "
occurs in an argument value? Replacing each  <at>  with  <at>  <at>  <at> atsign <at>  <at>  <at>  would
get ugly. But that's more of a theoretical issue than a practical
one.]

--

-- 
Glynn Clements <glynn <at> gclements.plus.com>
_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
Permalink | Reply | 5 comments |
headers
Dražen Odobašić | 2 Aug 2010 15:27
Picon
Gravatar

Projection doesn't use +towgs84 parameters

Hi,

i'm having an issue with transformation between two coordinate systems 
using cs2cs. I've noticed this while trying to use gdalwrap, but using 
cs2cs has same results.

This is what im trying to execute:

cs2cs +proj=tmerc +lat_0=0 +lon_0=15 +k=0.9999 +x_0=5500000 +y_0=0 
+ellps=bessel 
+towgs84=514.0188,155.448,507.0461,5.6136,3.676,-11.4667,0.9999979090043 
+units=m +no_defs +to +proj=tmerc +lat_0=0 +lon_0=16.5 +k_0=0.9999 
+x_0=500000 +ellps=WGS84 +units=m +no_defs -v
#
# ---- From Coordinate System ----
#
#Transverse Mercator
#
#       Cyl, Sph&Ell
#
# +proj=tmerc +lat_0=0 +lon_0=15 +k=0.9999 +x_0=5500000 +y_0=0 +ellps=bessel
#
# +towgs84=514.0188,155.448,507.0461,5.6136,3.676,-11.4667,0.9999979090043
#
# +units=m +no_defs
#
# ---- To Coordinate System ----
#
#Transverse Mercator
#
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jean-Claude REPETTO | 2 Aug 2010 16:03
Picon
Favicon

Re: Projection doesn't use +towgs84 parameters

Le 02/08/2010 15:27, Dražen Odobašić a écrit :
> Hi,
>
> i'm having an issue with transformation between two coordinate systems
> using cs2cs. I've noticed this while trying to use gdalwrap, but using
> cs2cs has same results.
>
> This is what im trying to execute:
>
> cs2cs +proj=tmerc +lat_0=0 +lon_0=15 +k=0.9999 +x_0=5500000 +y_0=0
> +ellps=bessel
> +towgs84=514.0188,155.448,507.0461,5.6136,3.676,-11.4667,0.9999979090043
> +units=m +no_defs +to +proj=tmerc +lat_0=0 +lon_0=16.5 +k_0=0.9999
> +x_0=500000 +ellps=WGS84 +units=m +no_defs -v

You have forgotten to give the +towgs84 parameters for the second CS.
Alternately, you could write "+datum=WGS84" instead of "+ellps=WGS84" .

Jean-Claude
_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
Permalink | Reply | 1 comment |
headers
Eric Miller | 2 Aug 2010 17:31
Favicon

Re: quoting +nadgrids ?

>>> On 8/1/2010 at 11:04 AM, Glynn Clements <glynn <at> gclements.plus.com> wrote:

> Frank Warmerdam wrote:
> 
>> I had proposed the  <at>  <at>  <at> space <at>  <at>  <at>  idea just because it wouldn't be interpreted
>> anywhere else, though it is somewhat peculiar.  Can you, or anyone,
>> provide an argument for a different approach?  Were you suggesting url
>> encoding because it was easily extended to other escaping operations?
> 
> Mostly because it's already known, can be used to escape arbitrary
> characters, the % sign seems (to me) unlikely to occur in an argument,
> and the worst case for the size of an escaped string isn't too bad
> (three times the size of the original string).
> 
> [Needless to say, the first question which crossed my mind regarding
> the  <at>  <at>  <at> space <at>  <at>  <at>  idea was: what happens if the text " <at>  <at>  <at> space <at>  <at>  <at> "
> occurs in an argument value? Replacing each  <at>  with  <at>  <at>  <at> atsign <at>  <at>  <at>  would
> get ugly. But that's more of a theoretical issue than a practical
> one.]

For whatever reason, the escape character for cmd.exe is the caret ^.  Besides the space character, the
following characters must be escaped: <, >, |, &, and ^ (of course).  Obviously, if you use this escaping
mechanism on Windows, the result won't be portable. URL encoding would not escape the ampersand, which
could be
trouble.

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/ntcmds_shelloverview.mspx?mfr=true 
--

-- 

Eric G. Miller
(Continue reading)

Permalink | Reply | 4 comments |
headers
Dražen Odobašić | 2 Aug 2010 18:30
Picon
Gravatar

Re: Projection doesn't use +towgs84 parameters

On 02.08.2010 16:03, Jean-Claude REPETTO wrote:
> Le 02/08/2010 15:27, Dražen Odobašić a écrit :
>> Hi,
>>
>> i'm having an issue with transformation between two coordinate systems
>> using cs2cs. I've noticed this while trying to use gdalwrap, but using
>> cs2cs has same results.
>>
>> This is what im trying to execute:
>>
>> cs2cs +proj=tmerc +lat_0=0 +lon_0=15 +k=0.9999 +x_0=5500000 +y_0=0
>> +ellps=bessel
>> +towgs84=514.0188,155.448,507.0461,5.6136,3.676,-11.4667,0.9999979090043
>> +units=m +no_defs +to +proj=tmerc +lat_0=0 +lon_0=16.5 +k_0=0.9999
>> +x_0=500000 +ellps=WGS84 +units=m +no_defs -v
>
> You have forgotten to give the +towgs84 parameters for the second CS.
> Alternately, you could write "+datum=WGS84" instead of "+ellps=WGS84" .
>
> Jean-Claude

Oh, yes, now it makes sense, to define a projection system one needs to 
define a datum.

Thank you very much
_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
Permalink | Reply | 0 comments |
headers
Glynn Clements | 2 Aug 2010 21:52

Re: quoting +nadgrids ?


Eric Miller wrote:

> >> I had proposed the  <at>  <at>  <at> space <at>  <at>  <at>  idea just because it wouldn't be interpreted
> >> anywhere else, though it is somewhat peculiar.  Can you, or anyone,
> >> provide an argument for a different approach?  Were you suggesting url
> >> encoding because it was easily extended to other escaping operations?
> > 
> > Mostly because it's already known, can be used to escape arbitrary
> > characters, the % sign seems (to me) unlikely to occur in an argument,
> > and the worst case for the size of an escaped string isn't too bad
> > (three times the size of the original string).
> > 
> > [Needless to say, the first question which crossed my mind regarding
> > the  <at>  <at>  <at> space <at>  <at>  <at>  idea was: what happens if the text " <at>  <at>  <at> space <at>  <at>  <at> "
> > occurs in an argument value? Replacing each  <at>  with  <at>  <at>  <at> atsign <at>  <at>  <at>  would
> > get ugly. But that's more of a theoretical issue than a practical
> > one.]
> 
> For whatever reason, the escape character for cmd.exe is the caret
> ^. Besides the space character, the following characters must be
> escaped: <, >, |, &, and ^ (of course). Obviously, if you use this
> escaping mechanism on Windows, the result won't be portable. URL
> encoding would not escape the ampersand, which could be trouble.

This issue has nothing (directly) to do with the shell on any
platform. It's simply an issue of how to represent a list of strings
as a single string.

Also, URL encoding can encode any character. The choice of which
(Continue reading)

Permalink | Reply | 3 comments |
headers
Eric Miller | 3 Aug 2010 00:02
Favicon

Re: quoting +nadgrids ?

>>> On 8/2/2010 at 12:52 PM, Glynn Clements <glynn <at> gclements.plus.com> wrote:

> Eric Miller wrote:
> 
>> >> I had proposed the  <at>  <at>  <at> space <at>  <at>  <at>  idea just because it wouldn't be interpreted
>> >> anywhere else, though it is somewhat peculiar.  Can you, or anyone,
>> >> provide an argument for a different approach?  Were you suggesting url
>> >> encoding because it was easily extended to other escaping operations?
>> > 
>> > Mostly because it's already known, can be used to escape arbitrary
>> > characters, the % sign seems (to me) unlikely to occur in an argument,
>> > and the worst case for the size of an escaped string isn't too bad
>> > (three times the size of the original string).
>> > 
>> > [Needless to say, the first question which crossed my mind regarding
>> > the  <at>  <at>  <at> space <at>  <at>  <at>  idea was: what happens if the text " <at>  <at>  <at> space <at>  <at>  <at> "
>> > occurs in an argument value? Replacing each  <at>  with  <at>  <at>  <at> atsign <at>  <at>  <at>  would
>> > get ugly. But that's more of a theoretical issue than a practical
>> > one.]
>> 
>> For whatever reason, the escape character for cmd.exe is the caret
>> ^. Besides the space character, the following characters must be
>> escaped: <, >, |, &, and ^ (of course). Obviously, if you use this
>> escaping mechanism on Windows, the result won't be portable. URL
>> encoding would not escape the ampersand, which could be trouble.
> 
> This issue has nothing (directly) to do with the shell on any
> platform. It's simply an issue of how to represent a list of strings
> as a single string.
(Continue reading)

Permalink | Reply | 2 comments |

Gmane