Martin wrote on 08/16/2006 03:06:02 PM:
> Paul Ramsey a écrit :
> > But, in the long term, what is the correct design way to handle
> > this? we have the "real" EPSG database, which will presumably be
> > updated over time, to include more and more projections as EPSG does
> > their work. And
Proj just uses the EPSG database, passed through a scripting process
to spit out the proj4 text representations. The "esri" file in there
is a set of esri ids I generated some years ago by taking all the
esri ids and differencing out all the epsg ids. I will do a similar
thing for geotool
Paul Ramsey ha scritto:
> It is not uncommon to find servers either deployed using ESRI
> technology, or simply following the ESRI lead, that advertise their
> SRS as "EPSG:102190" or some other > 10 "EPSG" code. ESRI in
> Arc* has the concept for CRS "ids" and for "ids" in the EPSG rang
I can provide a .properties file with the required information, no
problem. I will attach it to the JIRA when it is ready.
P
On 16-Aug-06, at 2:06 PM, Martin Desruisseaux wrote:
> Paul Ramsey a écrit :
>> But, in the long term, what is the correct design way to handle
>> this? we have the
Paul Ramsey a écrit :
> But, in the long term, what is the correct design way to handle
> this? we have the "real" EPSG database, which will presumably be
> updated over time, to include more and more projections as EPSG does
> their work. And we have some projection numbers like the ESRI a
It is not uncommon to find servers either deployed using ESRI
technology, or simply following the ESRI lead, that advertise their
SRS as "EPSG:102190" or some other > 10 "EPSG" code. ESRI in
Arc* has the concept for CRS "ids" and for "ids" in the EPSG range,
they have used the EPSG num
Over the past couple of weeks I have gotten a few private chat session
along the theme of "can we clean up X". Where X is 2.2.x or X is trunk
etc...
Specifically we have had some communication issues:
- please talk to a module maintainer and ask for a code review
- please be sure to not add Java
There also appears to be issues in ext/shaprenderer as well, some dom
classes also included in java 1.5 jdk have crept in as dependencies.
-Justin
Andrea Aime wrote:
> Justin Deoliveira ha scritto:
>> Hi all,
>>
>> I notice lately that I am running into obscure problems due to people
>> developi
Justin Deoliveira ha scritto:
> Hi all,
>
> I notice lately that I am running into obscure problems due to people
> developing with java 1.5. Just setting the 1.4 source compatability flag
> on the compiler does *not* ensure backwards compatabily. Especially when
> dealing with xml.
Heh, my bad,
Hi all,
I notice lately that I am running into obscure problems due to people
developing with java 1.5. Just setting the 1.4 source compatability flag
on the compiler does *not* ensure backwards compatabily. Especially when
dealing with xml.
The render module currently fails tests for me as sax d
The notes indicate that they are now beyond "simplified" docbook.
Still, if it's maven1...
On 16-Aug-06, at 9:47 AM, Andrea Aime wrote:
> Paul Ramsey ha scritto:
>> I have the PostGIS documentation in docbook. Going to HTML isn't
>> hard, going to PDF has been consistently flakey. And the
Paul Ramsey ha scritto:
> I have the PostGIS documentation in docbook. Going to HTML isn't hard,
> going to PDF has been consistently flakey. And the tools used to do all
> of this tend to be an admixture of stuff not always available on
> standard distributions. On the other hand, perhaps th
We have recently been using docbook to go to eclipse help files (this
has been great). We did try pdf and so
on but will have to ask Gerhard here for how effective it was in practice.
Jody
> I have the PostGIS documentation in docbook. Going to HTML isn't
> hard, going to PDF has been consiste
I have the PostGIS documentation in docbook. Going to HTML isn't
hard, going to PDF has been consistently flakey. And the tools used
to do all of this tend to be an admixture of stuff not always
available on standard distributions. On the other hand, perhaps the
Java world has solved thi
Actually funny that you ask. I am having problems with mail sent from
the topp server, it doesn't seem to be getting to the list. I will talk
to our sysadmin about it today.
-Justin
Andrea Aime wrote:
> Hi all,
> since everybody agrees that having cc running is a good thing, and
> since apparentl
Hi all,
since everybody agrees that having cc running is a good thing, and
since apparently TOPP is already running cc builds of some geotools
branches, could we have mail reports forwarded to the devel list
about successful/broken builds? Pretty please? :-p
Cheers
Andrea
Hi all,
before going all the way and using docbook again, did someone check that
we may be able to turn docbook stuff into pdf and html using maven2?
Otherwise it may become a hard call, since developers are split on
windows, various linux distros, and mac too.
Cheers
Andrea
-
Setup a plugin system for glyph renderers
-
Key: GEOT-924
URL: http://jira.codehaus.org/browse/GEOT-924
Project: GeoTools
Issue Type: Improvement
Components: core render
Affects Versions:
This page here:
http://udig.refractions.net/confluence/display/UDIG/Team+Project+Set+Import
Documents a nice quick way to grab the uDig source code, now that we
have the SDK release process working our target user
for this process (aka someone who wants to play right now) has a much
easier optio
19 matches
Mail list logo
