I'm on a Mac. The Django GeoDjango installation instructions are
somewhat obtuse and there aren't alternative sites I've found with
more straightforward instructions. It's lame that these are confusing
but, well, they are. I will no doubt review the sites you recommended.
Oh .. yeah, I've never tried installation on a Mac. Googling around a bit turns up http://lincolnloop.com/blog/2010/apr/30/installing-geodjango-dependencies-homebrew/ (as well as a lot of confusing stufff that scared me off) -- maybe that would Just Work?
As a newcomer who suddenly feels he may be biting off more than he can
chew, one of my worries it that if I utilize the sqlite3 database for
development with Spatialite, when I finally deploy this to, say, a
Postgres database, it won't transition correctly. This is most likely
due to my naiveté about databases, but I'm just concerned once it's
deployed, it won't work because I screwed something up by using
sqlite3 and I'm now trying to use another type of database.
That is a reasonable concern. For what it's worth, you're *likely* to not have any problems switching from sqlite to postgres midstream, as long as you stick to Django's ORM and querying methods; of course if you drop down into raw SQL problems will be more likely. I usually start out local development on sqlite and switch to postgres sometime later. But of course you're right that the most conservative approach is to pick one database and start with it.
From your textbook descriptions (awesome) it seems that GeoIP is what
I'm looking for. Essentially, a logged-in user's coordinates would be
taken from their IP address (not sure if GeoDjango has a way to do
this without front-end JS work (more terror))
Yes, using GeoIP doesn't require any front-end work. Your backend just gets an IP address with every request, and you can ask django.contrib.gis to locate that IP. Something like this: https://gist.github.com/1958529 -- which you would then store in your database through a GeoDjango PointField.
The problem with using HTML5 is, while it seems easy (there's pre-
formatted code out there that makes it a cinch to identify IP
location), it really provides no simple way to store or search for
content that's identified via GeoIP.
Literally speaking this is true, but you would use it in conjunction with backend code. HTML5 Geolocation is just concerned with reliably identifying the user's location on the client side. You could then write a bit of Javascript attached to your submission forms that inserts that location data into the form submission. Then on the server side, you have a lat/lng you can store with GeoDjango's PointField for future querying.
HTML5 Geolocation is most useful (and I believe has the most implementations) in the mobile world. If your users will be uploading content to your application from smartphones then this is a good feature to use.
It's best to think about (client-side) HTML5 Geolocation and (server-side) GeoIP as complementary features for graceful degredation. If data from HTML5 Geolocation is available, use it; if not, you can fall back on GeoIP. HTML5 Geolocation data, if present, is more likely to be both accurate and precise; geotagging content based on the user's IP address is a coarser-grained solution and can also return incorrect data in some circumstances -- depending on the details of the user's internet connection, the originating IP address could be somewhere else entirely.
- GeoDjango using the GeoIP features
- OpenLayers (have heard about it; need to research more)
- Google Maps or another mapping service, being wary of limits
Yup, that sounds right, with the caveat above that you may want to layer on HTML5 Geolocation as a progressive enhancement.
Hope this helps,
Ethan
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to django-users+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
No comments:
Post a Comment