Re: [OSGeo-Discuss] parsing coordinates
There is a new extension [1] for gvSIG able to do that [2]. [1] http://www.gvsig.gva.es/index.php?id=2187&L=0 [2] http://mmedia.uv.es/display?c=adiez&name=normalizar.mov On Apr 20, 2009, at 12:04 PM, pere roca ristol wrote: hi all, I'm developing a webapplication that let's user upload their point data and play with it. It currently works with lat/long in a CSV with this format (eg: 0.44, -79.9) but we find users with some of these also valid and acceptable ways to write geographic coordinates: 40:26:46N,79:56:55W 40:26:46.302N 79:56:55.903W 40°26'21"N 79°58'36"W 40d 26' 21" N 79d 58' 36" W 40.446195N 79.948862W 40.446195, -79.948862 40° 26.7717, -79° 56.93172 I'm aware that parsing and interpreting free-text coordinate descriptions is quite complex, maybe someone knows a script (or a remote service) that does a similar job? It would be very helpful. Thanks! Pere ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] trac non-functional
Howard Butler wrote:
On Jun 19, 2009, at 6:35 AM, Paolo Cavallini wrote:
Hi all.
Are there any plans to solve the horrible slowness and tendency to
return errors of the trac? We are working a lot on the qgis trac, but it
is a real pain, to the point that we are kind of thinking to write an
interface to the trac caching the results for quick search (what a waste
of time).
Paolo,
The problem is a volunteer manpower one. There are definitely plans, it
is just a matter of finding the time in which we can shut down and
implement them. I'm sorry that I can't give a better answer than that.
If you have time you can devote to the effort, please join the SAC list,
and we can get you up to date with all of the issues. We would happily
add another administrator of Trac if you have lots of familiarity with
it (especially mod_python, mod_wsgi and sqlite{1,3} vs external db like
pg).
Folks,
I have added a brief wiki topic on upgrade plans. Tentatively Howard
and myself will attempt to do something tomorrow night.
http://wiki.osgeo.org/wiki/Trac_Instances#Planned_Upgrade
It should be noted that there may be Trac unavailability for up to four
hours during the upgrade efforts.
Best regards,
--
---+--
I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush| Geospatial Programmer for Rent
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] trac non-functional
If a pgsql dba is needed, I can step up to that.
On Fri, Jun 19, 2009 at 7:01 AM, Howard Butler wrote:
>
> On Jun 19, 2009, at 6:35 AM, Paolo Cavallini wrote:
>
> Hi all.
>> Are there any plans to solve the horrible slowness and tendency to
>> return errors of the trac? We are working a lot on the qgis trac, but it
>> is a real pain, to the point that we are kind of thinking to write an
>> interface to the trac caching the results for quick search (what a waste
>> of time).
>>
>
> Paolo,
>
> The problem is a volunteer manpower one. There are definitely plans, it is
> just a matter of finding the time in which we can shut down and implement
> them. I'm sorry that I can't give a better answer than that. If you have
> time you can devote to the effort, please join the SAC list, and we can get
> you up to date with all of the issues. We would happily add another
> administrator of Trac if you have lots of familiarity with it (especially
> mod_python, mod_wsgi and sqlite{1,3} vs external db like pg).
>
> Howard___
>
> Discuss mailing list
> Discuss@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/discuss
>
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] trac non-functional
On Jun 19, 2009, at 6:35 AM, Paolo Cavallini wrote:
Hi all.
Are there any plans to solve the horrible slowness and tendency to
return errors of the trac? We are working a lot on the qgis trac,
but it
is a real pain, to the point that we are kind of thinking to write an
interface to the trac caching the results for quick search (what a
waste
of time).
Paolo,
The problem is a volunteer manpower one. There are definitely plans,
it is just a matter of finding the time in which we can shut down and
implement them. I'm sorry that I can't give a better answer than
that. If you have time you can devote to the effort, please join the
SAC list, and we can get you up to date with all of the issues. We
would happily add another administrator of Trac if you have lots of
familiarity with it (especially mod_python, mod_wsgi and sqlite{1,3}
vs external db like pg).
Howard
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] trac non-functional
Paolo Cavallini wrote: Hi all. Are there any plans to solve the horrible slowness and tendency to return errors of the trac? We are working a lot on the qgis trac, but it is a real pain, to the point that we are kind of thinking to write an interface to the trac caching the results for quick search (what a waste of time). Paolo, I was experiencing slow transfer some time ago (http://trac.osgeo.org/osgeo/ticket/383) Currently, Trac loads bloody fast for me, in London,UK. Cheers -- Mateusz Loskot, http://mateusz.loskot.net ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
[OSGeo-Discuss] trac non-functional
Hi all. Are there any plans to solve the horrible slowness and tendency to return errors of the trac? We are working a lot on the qgis trac, but it is a real pain, to the point that we are kind of thinking to write an interface to the trac caching the results for quick search (what a waste of time). All the best. -- Paolo Cavallini: http://www.faunalia.it/pc ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
