On 25/03/2014 00:01, Jed O. Kaplan wrote:
Dear Dmitriy,
Yes that is the correct projection code, but the problem is - and hence my
original question - that the “Times” projection referred to on the link you
sent me is not defined in proj4. I’m wondering if anyone has programmed it, or
if
Hi Jed,
I look at GDAL sources. The Times projection is supported in GDAL/OGR.
For example, you can user ESRI prj file as input parameter (s_srs,
t_srs). for gdalwarp/gdal_translate.
Best regards,
Dmitry
25.03.2014 3:01, Jed O. Kaplan пишет:
Dear Dmitriy,
Yes that is the correct
Dmitriy,
where did you find reference to the times projection in OGR ? I can't find it.
Even
--
Geospatial professional services
http://even.rouault.free.fr/services.html
Selon Dmitriy Baryshnikov bishop@gmail.com:
Hi Jed,
I look at GDAL sources. The Times projection is supported in
Hi,
answering some questions from Dmitry in the comment of
http://erouault.blogspot.ca/2014/03/draft-gdalogr-class-hierarchy-for-gdal.html#comment-form
:
A few questions:
1) Why the need GDALAbstractXXXDataset and GDALEmptyXXXDataset? May be
Abstract will be enouth?
-- The AbstractXXX has the
On 24/03/2014 21:46, Even Rouault wrote:
Hi,
Release soon, release early, so for people who like UML diagrams (there is
also a prototype of C++ classes for those who don't like UML very much), here's
a blog entry with the outcome of my thoughts for a possible re-organisation of
the GDAL/OGR
Hi Even,
hfadataset.cpp near 3686 ln
else if( EQUAL(pszProjName, Times) )
{
sPro.proNumber = EPRJ_TIMES;
sPro.proName = (char*) Times;
sPro.proParams[4] = oSRS.GetProjParm(SRS_PP_CENTRAL_MERIDIAN)*D2R;
sPro.proParams[6] = oSRS.GetProjParm(SRS_PP_FALSE_EASTING);
sPro.proParams[7] =
Dear Dmitriy,
Thanks again for your reply. I think you are right, there is support in GDAL
for the Times projection, but the projection itself needs to be defined in
proj4 somehow. When I try to run ogr2ogr with a simple world coastline file and
project it into the Times projection using the
Selon Dmitriy Baryshnikov bishop@gmail.com:
Hi Even,
hfadataset.cpp near 3686 ln
else if( EQUAL(pszProjName, Times) )
{
sPro.proNumber = EPRJ_TIMES;
sPro.proName = (char*) Times;
sPro.proParams[4] = oSRS.GetProjParm(SRS_PP_CENTRAL_MERIDIAN)*D2R;
sPro.proParams[6] =
Ouch, sorry. I think that if HFA driver support this projection it's
everything is OK.
Best regards,
Dmitry
25.03.2014 14:49, Even Rouault пишет:
Selon Dmitriy Baryshnikov bishop@gmail.com:
Hi Even,
hfadataset.cpp near 3686 ln
else if( EQUAL(pszProjName, Times) )
{
sPro.proNumber =
On 25/03/2014 11:44, Even Rouault wrote:
Selon Vincent Mora vincent.m...@oslandia.com:
On 24/03/2014 21:46, Even Rouault wrote:
Hi,
Release soon, release early, so for people who like UML diagrams (there
is
also a prototype of C++ classes for those who don't like UML very much),
here's
a
According to naming conventions I think, that pure interface classes
should start with I (e.g. IGDALRasterDataset, IGDALVectorDataset).
For the Abstract class maybe such naming will sute:
GDALEmptyRasterDataset - GDALRasterDataset
GDALAbstractRasterDataset - GDALRasterDatasetBase
Selon Vincent Mora vincent.m...@oslandia.com:
On 25/03/2014 11:44, Even Rouault wrote:
Selon Vincent Mora vincent.m...@oslandia.com:
On 24/03/2014 21:46, Even Rouault wrote:
Hi,
Release soon, release early, so for people who like UML diagrams (there
is
also a prototype of C++
Partial sound ok to me, but I not so good at naming ?
Considering the number of classes, I gave it some thoughts this morning
and, like Dmitry, thought of merging the Abtract (Partial) into the
interface before realizing that, even if it works (you can overload de
default function in Empty)
On 25 March 2014 12:37, Dmitriy Baryshnikov bishop@gmail.com wrote:
According to naming conventions I think, that pure interface classes should
start with I (e.g. IGDALRasterDataset, IGDALVectorDataset).
For the Abstract class maybe such naming will sute:
GDALEmptyRasterDataset -
I also (respectfully) think that there are too many classes (mostly the
abstract classes and interfaces) which make it a bit hard to understand.
I like Vincent's second suggestion to have 3 base Dataset classes
(GDALRasterDataset, GDALVectorDataset, GDALHybridDataset) which inherit
from
Selon Etienne Tourigny etourigny@gmail.com:
I also (respectfully) think that there are too many classes (mostly the
abstract classes and interfaces) which make it a bit hard to understand.
I like Vincent's second suggestion to have 3 base Dataset classes
(GDALRasterDataset,
Hi,
GDAL 1.10 was released about one year ago, so it is time to think about the next
release. I think we should just call it 1.11 given that there are no major
architectural changes (although there have been non trivial changes in RAT
management and for multiple geometry field support, but that
That sounds good to me.
Best regards,
Tamas
2014-03-25 22:37 GMT+01:00 Even Rouault even.roua...@mines-paris.org:
Hi,
GDAL 1.10 was released about one year ago, so it is time to think about
the next
release. I think we should just call it 1.11 given that there are no major
Good plan!
Best regards,
Dmitry
26.03.2014 1:57, Tamas Szekeres ?:
That sounds good to me.
Best regards,
Tamas
2014-03-25 22:37 GMT+01:00 Even Rouault even.roua...@mines-paris.org
mailto:even.roua...@mines-paris.org:
Hi,
GDAL 1.10 was released about one year ago, so it is
19 matches
Mail list logo
