Hi!
I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
t
I have installed python 3.7.5 64 bit. GDAL 2.4.4 and corresponding python
gdal from
http://www.gisinternals.com/query.html?content=filelist&file=release-1900-gdal-2-4-4-mapserver-7-4-3.zip
I
have also set environment variables correctly. I did a gdalinfo --version
from command prompt, i could
performance when storing large geospatial datasets.
>
> This would only work on PostGIS.
>
> On Thursday, December 15, 2016 at 3:11:37 PM UTC-5, Adam
> Johnson wrote:
>
> I can't say I'm that familiar w
ember 20, 2016 at 11:27:25 AM UTC-5, Piero Toffanin wrote:
>>>
>>> It's stored on the file system. This is to improve performance when
>>> storing large geospatial datasets.
>>>
>>> This would only work on PostGIS.
>>>
>>> On Thurs
performance when
>> storing large geospatial datasets.
>>
>> This would only work on PostGIS.
>>
>> On Thursday, December 15, 2016 at 3:11:37 PM UTC-5, Adam Johnson wrote:
>>>
>>> I can't say I'm that familiar with GeoDjango, but that do
It's stored on the file system. This is to improve performance when storing
large geospatial datasets.
This would only work on PostGIS.
On Thursday, December 15, 2016 at 3:11:37 PM UTC-5, Adam Johnson wrote:
>
> I can't say I'm that familiar with GeoDjango, but that does s
wrote:
>
> It's stored on the file system. This is to improve performance when
> storing large geospatial datasets.
>
> This would only work on PostGIS.
>
> On Thursday, December 15, 2016 at 3:11:37 PM UTC-5, Adam Johnson wrote:
>>
>> I can't say I'm tha
I can't say I'm that familiar with GeoDjango, but that does sound like a
useful feature. Where does the data get stored if not in the DB? And does
this feature exist on any of the other database backends that GeoDjango
supports?
On 14 December 2016 at 18:40, Piero Toffanin wrote
Hello,
Not sure this is the right place to post this, if not, could somebody point
me to the right place?
I recently had the need to use GeoDjango to define a model that uses a
RasterField to store a GeoTIFF
raster.
https://docs.djangoproject.com/en/1.10/ref/contrib/gis/model-api
wrote:
>
> Great to hear, GeoDjango documentation has always seemed half-finished to
> me, and only useful to people who are already familiar with GIS terminology.
>
> Based on my impressions from various forum posts over the years, beginners
> who are looking at GeoDjango:
> *
Great to hear, GeoDjango documentation has always seemed half-finished to
me, and only useful to people who are already familiar with GIS terminology.
Based on my impressions from various forum posts over the years, beginners
who are looking at GeoDjango:
* Have never heard about OGC geometries
Hello,
I'm currently working on ticket #22274
<https://code.djangoproject.com/ticket/22274>, which is an effort to
improve the GeoDjango documentation to make it more accessible to
newcomers. This represents quite some work and I'm still in the early
stages but I'd love to
Just to follow up this issue was cleared up in django 1.8.1
https://code.djangoproject.com/ticket/24724
On Tuesday, February 3, 2015 at 12:04:37 AM UTC-8, Claude Paroz wrote:
>
> Le lundi 2 février 2015 17:30:23 UTC+1, mattxbart a écrit :
>>
>> Hi all,
>> I had a workin
Le lundi 2 février 2015 17:30:23 UTC+1, mattxbart a écrit :
>
> Hi all,
> I had a working 1.7.4 (using geodjango) on windows 7 install, no issues.
> I'm using osgeo4w to manage all the gdal/gis libraries. When I install the
> django 1.8a release or off git master, I get the
Hi all,
I had a working 1.7.4 (using geodjango) on windows 7 install, no issues.
I'm using osgeo4w to manage all the gdal/gis libraries. When I install the
django 1.8a release or off git master, I get the following traceback:
$ ./manage.py shell
Traceback (most recent call last):
Hi Daniel,
I've answered on the GeoDjango list. Please avoid cross-posting, thanks.
Claude
Le mercredi 12 novembre 2014 12:34:34 UTC+1, Daniel Wiesmann a écrit :
>
> Hi All
>
> I am wondering if integration of Raster data is on the roadmap of
> GeoDjango.
>
> I am ask
Hi All
I am wondering if integration of Raster data is on the roadmap of GeoDjango.
I am asking because I have started to work on a package to include Rasters
into Django (see link below). This is still very early stage, but I already
use the package in a Django project I am working on. For
.
Does anyone know of a native GeoDjango solution to this?
If not, should I create a patch that incorporates this functionality
in GeoDjango?
Or handling of IDL in the above case would be considered not within
the scope of the framework?
Thanks,
Val
--
You received this message because you are
l Neekman:
>>
>> If you build a geom with a bounding box that contains IDL (International
>> Date Line) and run a point__within query on it, then the result is
>> unpredictable and incorrect.
>>
>> Does anyone know of a native GeoDjango solution to this?
>
s anyone know of a native GeoDjango solution to this?
>
> If not, would there be a lot of resistance against a patch that
> incorporates this functionality in GeoDjango?
>
>
> Val
> Sent from my mobile device.
>
> On 2013-03-17, at 12:39 AM, Omer Katz >
> wrote:
If you build a geom with a bounding box that contains IDL (International Date
Line) and run a point__within query on it, then the result is unpredictable and
incorrect.
Does anyone know of a native GeoDjango solution to this?
If not, would there be a lot of resistance against a patch that
On Tue, Feb 12, 2013 at 10:21 AM, Val Neekman wrote:
> If I had to choose between GeoDjango and South as a core package, I'd go with
> South for sure.
FTR, that's in the works.
Jacob
--
You received this message because you are subscribed to the Google Groups
"Django
Yeah, it's amazing that we have GeoDjango included as I'm using it right now.
However I can fall back to geopy and still getaway with rough acceptable
estimates with limited scope and capability which I'm fine with. (In my use
case)
If I had to choose between GeoDjango and
The only historically-accurate answer is: "because it seemed like a
good idea at the time."
Remember, this was 2008. So one problem was that Django's DB APIs
weren't very polished, so GeoDjango had to do a bunch of trickery.
Bringing it into core gave a good way towards push
I've seen lot of talk about removing the admin and many other contribs from
core.
For some I think it make sense, for others like the admin I'm not so sure.
However, I have not seen any talk about removing GeoDjango and I'm
wondering about the
rational of keeping this relativ
On Wed, 2012-05-30 at 05:05 -0700, Václav Řehák wrote:
> > Has anybody tested GDAL 1.9 or Proj 4.8? I've seen, ubuntu uses GDAL 1.7
> > (and gdal 1.9 for the next release). Is there any known test case to
> > check, if geodjango works with proj 4.8 and/or GDAL 1.9?
>
>
> Has anybody tested GDAL 1.9 or Proj 4.8? I've seen, ubuntu uses GDAL 1.7
> (and gdal 1.9 for the next release). Is there any known test case to
> check, if geodjango works with proj 4.8 and/or GDAL 1.9?
I haven't tested myself but the chances are high that some tweaks are
ne
ntu uses GDAL 1.7
(and gdal 1.9 for the next release). Is there any known test case to
check, if geodjango works with proj 4.8 and/or GDAL 1.9?
Thanks,
Matthias
--
Matthias Runge
--
You received this message because you are subscribed to the Google Groups
"Django developers&q
ibility could exist:
I've been using GeoDjango on my Fedora desktop with no issues
>
> I was also wondering about PostGIS 2.0, although there is no Fedora
> package yet.
I believe PostGIS 2.0 isn't supported yet:
https://code.djangoproject.com/ticket/16455
Chris
--
You receiv
Hello!
https://docs.djangoproject.com/en/dev/ref/contrib/gis/install/#requirements
lists GeoDjango's version requirements.
Fedora ships newer versions of those libraries. I was wondering whether
any incompatibility could exist:
Fedora has:
Proj 4.8
GDAL 1.9
I was also wondering about PostGIS
Hi.
As in
http://groups.google.com/group/geodjango/browse_thread/thread/a4e8d89fb355009b/7167f9bef1b4e546?lnk=gst&q=v3#7167f9bef1b4e546
I saw some moves into migrating to Google Maps API v3, mostly because
it will be deprecated soon.
I started to work on it because this new version have
ote:
>
>
> On Nov 9, 6:25 am, Paul McMillan wrote:
>> I opened #14527 a while ago, but it hasn't gotten much
>> attention.http://code.djangoproject.com/ticket/14527
>>
>> It would fix the docs which claim that PostGIS doesn't support PostgreSQL
>>
On Nov 9, 6:25 am, Paul McMillan wrote:
> I opened #14527 a while ago, but it hasn't gotten much
> attention.http://code.djangoproject.com/ticket/14527
>
> It would fix the docs which claim that PostGIS doesn't support PostgreSQL 8.4.
>
> Can I get some GeoDjan
I opened #14527 a while ago, but it hasn't gotten much attention.
http://code.djangoproject.com/ticket/14527
It would fix the docs which claim that PostGIS doesn't support PostgreSQL 8.4.
Can I get some GeoDjango users to chime in on this matter? I'd like to
see this closed one w
On Nov 14, 2007 8:41 AM, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> So, to sum up, I'd prefer merges from trunk less often, but understand
> others may prefer more often. Even with frequent merges, I don't have
> to take the merge-- but cherry-picking is extra work.
We've never really enforced th
rk to adjust to. (I'm not complaining, I'm happy to see
the feature added-- I just hadn't planned that time right now.)
I know there are some folks that have GeoDjango code in production
now, and their concerns are important, too.The general branch
merge policy for Django is:
&qu
You can read this thread, and someone given a patch, you can test it.
The newest code is in the svn.
--
I like python!
UliPad <>: http://code.google.com/p/ulipad/
meide <>: http://code.google.com/p/meide/
My Blog: http://www.donews.net/limodou
--~--~-~--~~~---~--~---
On 10/27/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> def setSequence(cursor, model):
>from django.conf import settings
>
># postgresql: reset sequence
>if settings.DATABASE_ENGINE in ('postgresql_psycopg2',
> 'postgresql'):
> try:
> f = model._meta.get_fiel
def setSequence(cursor, model):
from django.conf import settings
# postgresql: reset sequence
if settings.DATABASE_ENGINE in ('postgresql_psycopg2',
'postgresql'):
try:
f = model._meta.get_field('id')
except FieldDoesNotExist:
f = None
if f
On 10/27/07, Matthew Wensin <[EMAIL PROTECTED]> wrote:
>
> I suspected the script as well, but when I first asked the question in
> #django, I was told by a pretty experienced Djangonista that the
> "django_session_iq_seq" sequence should exist. As such I assumed it was a
> problem with GeoDj.
>
ies with the script's handling of models that use primary
> keys outside the implicit AutoField -- most likely this is not related
> to GeoDjango.
>
> -Justin
>
>
> >
--~--~-~--~~~---~--~~
You received this message because you are
, the
primary key is manually specified for the `session_key` field --
therefore no AutoField is created for the Session model. My guess is
the bug lies with the script's handling of models that use primary
keys outside the implicit AutoField -- most likely this is not related
to GeoDjango
GeoDjango such that this isn¹t being created?
Matt
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubs
ill work for
this project. I'll try to get you more details eventually.
Matt
-Original Message-
From: django-developers@googlegroups.com
[mailto:[EMAIL PROTECTED] On Behalf Of Justin Bronn
Sent: Wednesday, September 19, 2007 11:10 AM
To: Django developers
Subject: Re: GeoDjango: S
Matt,
I'm having difficulty reproducing this error, as the objects I create
from the admin save ok.
Can you provide the code for your model and/or a more verbose
traceback? Are you using psycopg2? Have you modified any parts of
the code, especially any GEOS components?
I ask because the GEOS
Trying to create a feature (in the Django admin) using text such as
'POINT(-80 25)' I get an error back from PostgreSQL:
ProgrammingError: Input geometry has unknown (-1) SRID
The documentation says SRID=4326 is the default, but this must not be
getting passed through. In fact, if I look at th
@googlegroups.com
[mailto:[EMAIL PROTECTED] On Behalf Of Justin Bronn
Sent: Friday, September 14, 2007 1:49 PM
To: Django developers
Subject: Re: GeoDjango installation instructions correction?
> If I am understanding things correctly, GeoDjango uses ST_* functions
> in PostgreSQL, but these fun
> If I am understanding things correctly, GeoDjango uses ST_* functions in
> PostgreSQL, but these functions weren't added until 1.2.1.
I started developing GeoDjango when PostGIS 1.2.1 was the latest. I
believe PostGIS began adding the ST_* routines in 1.2.1, and in 1.3.1
they dep
The installation instructions for GeoDjango say:
* Required: PostGIS v1.1.0 and above.
* Recommended: Postgis v1.2.1 PostGIS
<http://postgis.refractions.net/download/> and greater. The latest
version of PostGIS is v1.3.1
<http://postgis.refractions.net/news
On 9/13/07, Wensing, Matthew (CNI-Palm Beach) <[EMAIL PROTECTED]> wrote:
> Can someone tell me if there's a GeoDjango IRC channel? Who can I talk to
> about the project?
The main developers on the project are Jeremy Dunck (jdunck) and
Justin Bronn (jbronn); they both read djan
Can someone tell me if there's a GeoDjango IRC channel? Who can I talk
to about the project?
Thanks,
Matt
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to t
it has a few changes that allow it to
use the PostGIS lookup types. Thus, when you have no GeoManager, the
regular Manager is used and it has no clue what to do with the
geographic lookup types. Therefore, GeoManager needs to be used
whenever geographic queries are needed.
I'll try and put s
I wouldn't think this would actually work but I just put the objects =
models.GeoManager() on my model and it now knows what to do with the
spatial queries. Excellent.
On 4/17/07, mattxbart <[EMAIL PROTECTED]> wrote:
> Hey guys, I'm working with the GeoDjango branch and
Hey guys, I'm working with the GeoDjango branch and I was wondering if
there are any plans to allow something like I have below:
>>> ParcelSale.objects.filter(parcel__poly__contained=cpa.get_poly_wkt())
"parcel" is a foreign key to the geometry model information:
c
On 2/26/07, Travis Pinney <[EMAIL PROTECTED]> wrote:
> Hi Jeremy,
>
> I have geometric queries working now.
>
> Right now I have it set up as
>
> bbox = "POLYGON((-95.36819458007812
> 30.2184318620219,-95.36819458007812
> 30.084840018486364,-95.55702209472656
> 30.084840018486364,-95.5570220947265
55 matches
Mail list logo
