Das deutsche Python-Forum

Hallo,

ich möchte mit Django eine Seite basteln auf der User Orte eintragen und finden können. Konkret: Pommesbudenbetreiber Kartoffel Karl trägt seine Pommesbude ein inkl. Geodaten (Adresse) und Pommesesser Majo Martin kann dann den kürzesten Weg zu Kartoffel Karl finden, wenn er in sein mobiles Endgerät eingibt "Zeige mir alle Pommesbuden im Umkreis von 200 m um meinen Standort" bzw., besser zum Beispiel oben passend "Zeige mir die Entfernung von meinem Standort bis zum Kartoffel Karl".

Wie und mit welchen Datenbanken kann ich das am besten realisieren? Und das am allerbesten noch als Cloudinstallation?

So, wie es in der GeoDjango Dokumentation steht, kommen folgende DB-Erweiterungen infrage:

1. PostGIS
2. SpatiaLite
3. GEOS

Letztes ist für alle Datenbanksysteme (PostgreSQL, MySQL, Oracle und SQLite) notwendig. Am ehesten infrage kommt bei mir wohl die Datenbank PostgreSQL (aber wenn was anderes besser funktioniert: gerne auch die Alternative!).

Dann kann man noch die entsprechende Google Projektion dazuinstallieren.

Und jetzt sind wir an dem Punkt, wo ich nicht mehr weiterkomme:

1) Grundsätzlich ist mir unklar, was das Besondere an Geodaten ist. Warum kann ich Längen- und Breitengrade nicht ganz einfach in Tabellen eintragen wie andere Daten auch?

2) Wie bringe ich das Ganze in Verbindung mit einem der gängigen Web-Kartendienste, also Google Maps oder Bing Maps oder Openstreetmap?

3) Im Grunde könnten die Pommesbuden im Beispiel ja auch direkt in den jew. Kartendienst eingetragen und die Jarte dann einfach eingebunden werden. Wo liegt jetzt hier mein Denkfehler?

4) Und iwe harmonieren die Sachen mit Djangos ORM?


Damit die Probleme nicht so schnell behoben sind, kommt jetzt noch der Extrawunsch: am liebsten soll das ganze als Cloudinstallation realisiert werden. Googelt man, findet man viele private Anbieter mit speziellen Dienstleistungen dazu- aber wenige freie (keine?) Lösungen.

Da Googles App Engine netterweise bereits eine Djangoinstallation bereithält, wäre es natürlich schön, wenn dann auch die Geodaten dort untergebracht werden könnten. Das sieht, nach meiner bisherigen Recherche wenigstens, nicht so toll aus. Es gibt nur eine GIScloud, die aber nur auf Java läuft.

Wie bekomme ich das alles zusammen?


Danke schonmal im Voraus!

@Py-Paul: 1) Das besondere sind unter anderem die räumlichen Abfragen. Eine Abfrage wie „Ich habe hier diesen Punkt, liefere mir bitte alle Punkte aus der DB die maximal x Meter entfernt sind” soll ja idealerweise die *Datenbank* beantworten. Und das effizient. Da braucht man also Datentypen in der Datenbank für die Punkte, Operatoren und Funktionen die auf diesem neuen Datentypen operieren, und damit es effizient wird, auch Indexstrukturen die nicht nur ”eindimensionale Ordnungen” haben.

3) Ja das könnten die Buden machen. Da hast Du keinen Denkfehler.

Die Extraanforderung mit der Cloud ist ziemlich nebulös bis wolkig, denn was ist denn für Dich eine Cloud? Es gibt Cloudanbieter bei denen man komplette Linuxinstallationen wolkig zur Verfügung gestellt bekommt und andere mit fest vorgegebenen Bausteinen und einer API gegen die man programmieren muss. „Cloud” ist kein wirklich scharf umrissener Begriff. Warum denkst Du denn das in der Wolke haben zu müssen?

Py-Paul hat geschrieben:2) Wie bringe ich das Ganze in Verbindung mit einem der gängigen Web-Kartendienste, also Google Maps oder Bing Maps oder Openstreetmap?

Willst du die Sachen dort eintragen? Oder willst du die Informationen selbst in deiner Datenbank speichern? Für ersteres brauchst du GeoDjango natürlich nicht.

Py-Paul hat geschrieben:4) Und iwe harmonieren die Sachen mit Djangos ORM?

Ganz brauchbar, zumindest ab 1.5 wurden die Bugs die ich in GeoDjango (1.4) hatte dann upstream gefixt.

Py-Paul hat geschrieben:Damit die Probleme nicht so schnell behoben sind, kommt jetzt noch der Extrawunsch: am liebsten soll das ganze als Cloudinstallation realisiert werden. Googelt man, findet man viele private Anbieter mit speziellen Dienstleistungen dazu- aber wenige freie (keine?) Lösungen.

Was heißt freie Cloudlösung? Irgendwer muss ja den Server betreiben. Was am ehesten zu freier Cloud-Lösung passen würde wäre wohl OpenShift von RedHat.

Py-Paul hat geschrieben:Da Googles App Engine netterweise bereits eine Djangoinstallation bereithält, wäre es natürlich schön, wenn dann auch die Geodaten dort untergebracht werden könnten. Das sieht, nach meiner bisherigen Recherche wenigstens, nicht so toll aus. Es gibt nur eine GIScloud, die aber nur auf Java läuft.

GAE würde ich nicht nutzen, dort ist das in Django ziemlich umgebaut um mit der Google-Datenbank zu kunktionieren und wenn man spezielle Anforderungen wie GeoDjango hat dann sucht man sich besser Alternativen.

Hallo,

BlackJack hat geschrieben:@Py-Paul: 1) Das besondere sind unter anderem die räumlichen Abfragen. Eine Abfrage wie „Ich habe hier diesen Punkt, liefere mir bitte alle Punkte aus der DB die maximal x Meter entfernt sind” soll ja idealerweise die *Datenbank* beantworten. Und das effizient. Da braucht man also Datentypen in der Datenbank für die Punkte, Operatoren und Funktionen die auf diesem neuen Datentypen operieren, und damit es effizient wird, auch Indexstrukturen die nicht nur ”eindimensionale Ordnungen” haben.

Verstehe...- gibt es dazu iwo ein gutes Anfängertutorial? Ich habe bis jetzt nichts passendes gefunden...

BlackJack hat geschrieben:3) Ja das könnten die Buden machen. Da hast Du keinen Denkfehler.

OK... ich habe da leider einen Knoten im Hirn... Kann ich dann nicht die Suchanfragen über die jeweiligen Kartenanbieter laufen lassen? Hmmm... die Antwort müsste offensichtlich "Ja" lauten, aber irgendwas stört mich dabei... was habe ich da übersehen? :K

BlackJack hat geschrieben:Die Extraanforderung mit der Cloud ist ziemlich nebulös bis wolkig, denn was ist denn für Dich eine Cloud? Es gibt Cloudanbieter bei denen man komplette Linuxinstallationen wolkig zur Verfügung gestellt bekommt und andere mit fest vorgegebenen Bausteinen und einer API gegen die man programmieren muss. „Cloud” ist kein wirklich scharf umrissener Begriff. Warum denkst Du denn das in der Wolke haben zu müssen?

Erfahrungswerte habe ich Null (wie wahrscheinlich momentan noch die meisten anderen). Ich denke da an eine gemanagede (schreibt man das so?) Cloud mit "fertigen" Software Stacks (also hier: Django), die möglichst aktuell und unverändert sein sollen- also "Platform as a Service". Hier sehe ich folgende Vorteile:

1. problemlose Skalierbarkeit
2. kein Stress mit Serveradministration etc.
3. Konzentration auf die eigentliche Entwicklungsarbeit
4. im Vergleich evtl. sogar preislich günstig

Zumindest am Anfang eines Projekts würde ich so einen PaaS [Platform as a Service]- Dienst recht nett finden- wenn das Projekt dann unwahrscheinlicherweise doch erfolgreich werden sollte, dann könnte man immer noch umziehen in eine andere Cloud ohne PaaS. Das hört sich jedenfalls für meine Ohren nach einer sinnvollen Strategie an

Wenn man sucht, dann scheinen alle Anbieter in den USA zu sein (?). Gefunden habe ich u.a. (zufällige Auswahl):
http://bitnami.com/stack/django/cloud
http://www.docker.io/ --> Das habe ich nicht ganz gecheckt... Es sieht so aus, als könne man sich damit selbst ein PaaS bauen....
https://www.openshift.com/blogs/rapid-p ... ith-a-paas
---> aber wohl auch zum "selbstmachen"... :K

Also durchblicken tue ich hier nicht gerade....

Hat den hier jemand Erfahrungen mit sowas?
Wo liegen die Unterschiede?


Schließlich noch eine sehr wichtige Frage:

Ich möchte als DB am liebsten PostgreSQL mit PostGIS nehmen. Ich bin mir aber nicht sicher, ob es hierbei Unterschiede zwischen Betrieb auf einem "normalen, konventionellen Server" und "in der Cloud" gibt. Müsste ich Änderungen vornehmen, wenn ich zwischen diesen Hostingvarianten wechsle? Wenn ja: welche? Bzw.: wie aufwendig würde das?

Um das etwas auzudehnen: Wie sieht es mit NoSQL DBs aus? wäre dabei der Wechsel unproblematischer (da diese ja angeblich problemlos in der Cloud laufen)? Aber da stößt man ja wieder auf das Problem, dass Django keine NoSQL-DBs unterstützt (und Django nonrel wohl auch nicht so richtig vorankommt).... :-/

Hallo,

[Anmerkung: ein paar Sachen überschneiden sich mit dem Post vorher; Forensoftware sieht leider kein "Sammeln von Zitaten" vor]

Leonidas hat geschrieben:

Py-Paul hat geschrieben:2) Wie bringe ich das Ganze in Verbindung mit einem der gängigen Web-Kartendienste, also Google Maps oder Bing Maps oder Openstreetmap?

Willst du die Sachen dort eintragen? Oder willst du die Informationen selbst in deiner Datenbank speichern? Für ersteres brauchst du GeoDjango natürlich nicht.

Ja, das ist der Punkt, wo ich mir unsicher bin, siehe oben. Es stellt sich die Frage, ob es nicht sinnvoller, da wesentlich einfacher wäre, zumindest anfangs alles über den jeweiligen Kartendienst abzuwickeln.

Leonidas hat geschrieben:

Py-Paul hat geschrieben:Damit die Probleme nicht so schnell behoben sind, kommt jetzt noch der Extrawunsch: am liebsten soll das ganze als Cloudinstallation realisiert werden. Googelt man, findet man viele private Anbieter mit speziellen Dienstleistungen dazu- aber wenige freie (keine?) Lösungen.

Was heißt freie Cloudlösung? Irgendwer muss ja den Server betreiben. Was am ehesten zu freier Cloud-Lösung passen würde wäre wohl OpenShift von RedHat.

Siehe auch letztes Posting
Ja, da hast Du recht- das mit der "freien Cloudlösung" ist so gesehen unsinn

Leonidas hat geschrieben:

Py-Paul hat geschrieben:Da Googles App Engine netterweise bereits eine Djangoinstallation bereithält, wäre es natürlich schön, wenn dann auch die Geodaten dort untergebracht werden könnten. Das sieht, nach meiner bisherigen Recherche wenigstens, nicht so toll aus. Es gibt nur eine GIScloud, die aber nur auf Java läuft.

GAE würde ich nicht nutzen, dort ist das in Django ziemlich umgebaut um mit der Google-Datenbank zu kunktionieren und wenn man spezielle Anforderungen wie GeoDjango hat dann sucht man sich besser Alternativen.

Ja, den Eindruck habe ich jetzt auch....

Gibt es denn hier Erfahrungen zum Thema "Django-Cloud-PostgreSQL/PostGIS-funktioniertallesbestens"?
Irgendwelche Anbieter,die empfohlen werden können?

Py-Paul hat geschrieben:

BlackJack hat geschrieben:@Py-Paul: 1) Das besondere sind unter anderem die räumlichen Abfragen. Eine Abfrage wie „Ich habe hier diesen Punkt, liefere mir bitte alle Punkte aus der DB die maximal x Meter entfernt sind” soll ja idealerweise die *Datenbank* beantworten. Und das effizient. Da braucht man also Datentypen in der Datenbank für die Punkte, Operatoren und Funktionen die auf diesem neuen Datentypen operieren, und damit es effizient wird, auch Indexstrukturen die nicht nur ”eindimensionale Ordnungen” haben.

Verstehe...- gibt es dazu iwo ein gutes Anfängertutorial? Ich habe bis jetzt nichts passendes gefunden...

GeoDjango-Tutorial ist doch schonmal ein guter Anfang.

Py-Paul hat geschrieben:

BlackJack hat geschrieben:3) Ja das könnten die Buden machen. Da hast Du keinen Denkfehler.

OK... ich habe da leider einen Knoten im Hirn... Kann ich dann nicht die Suchanfragen über die jeweiligen Kartenanbieter laufen lassen? Hmmm... die Antwort müsste offensichtlich "Ja" lauten, aber irgendwas stört mich dabei... was habe ich da übersehen? :K

Das geht, wenn die Kartenanbieter deine Buden aufnehmen (sind ja nicht dazu verpflichtet) und so eine API bereitstellen. Ob sie so etwas tun ist halt die Frage.

Py-Paul hat geschrieben:

BlackJack hat geschrieben:Die Extraanforderung mit der Cloud ist ziemlich nebulös bis wolkig, denn was ist denn für Dich eine Cloud? Es gibt Cloudanbieter bei denen man komplette Linuxinstallationen wolkig zur Verfügung gestellt bekommt und andere mit fest vorgegebenen Bausteinen und einer API gegen die man programmieren muss. „Cloud” ist kein wirklich scharf umrissener Begriff. Warum denkst Du denn das in der Wolke haben zu müssen?

Erfahrungswerte habe ich Null (wie wahrscheinlich momentan noch die meisten anderen). Ich denke da an eine gemanagede (schreibt man das so?) Cloud mit "fertigen" Software Stacks (also hier: Django), die möglichst aktuell und unverändert sein sollen- also "Platform as a Service". Hier sehe ich folgende Vorteile:

1. problemlose Skalierbarkeit
2. kein Stress mit Serveradministration etc.
3. Konzentration auf die eigentliche Entwicklungsarbeit
4. im Vergleich evtl. sogar preislich günstig

Zumindest am Anfang eines Projekts würde ich so einen PaaS [Platform as a Service]- Dienst recht nett finden- wenn das Projekt dann unwahrscheinlicherweise doch erfolgreich werden sollte, dann könnte man immer noch umziehen in eine andere Cloud ohne PaaS. Das hört sich jedenfalls für meine Ohren nach einer sinnvollen Strategie an

Wenn man sucht, dann scheinen alle Anbieter in den USA zu sein (?). Gefunden habe ich u.a. (zufällige Auswahl):
http://bitnami.com/stack/django/cloud
http://www.docker.io/ --> Das habe ich nicht ganz gecheckt... Es sieht so aus, als könne man sich damit selbst ein PaaS bauen....
https://www.openshift.com/blogs/rapid-p ... ith-a-paas
---> aber wohl auch zum "selbstmachen"... :K

Also durchblicken tue ich hier nicht gerade....

Hat den hier jemand Erfahrungen mit sowas?
Wo liegen die Unterschiede?

Docker ist für Entwicklung gedacht, dass du dir Container lokal auf dem Rechner startest und dort deine Entwicklung machst. Ich finde für den Anfang ist dieses Cloud-Zeug eher schwerer zu verstehen als eine "normale" Installation auf einem vServer. Was du suchst ist eventuell Heruko, aber das ist, meiner Meinung nach alles andere als günstig.

Py-Paul hat geschrieben:Schließlich noch eine sehr wichtige Frage:

Ich möchte als DB am liebsten PostgreSQL mit PostGIS nehmen. Ich bin mir aber nicht sicher, ob es hierbei Unterschiede zwischen Betrieb auf einem "normalen, konventionellen Server" und "in der Cloud" gibt. Müsste ich Änderungen vornehmen, wenn ich zwischen diesen Hostingvarianten wechsle? Wenn ja: welche? Bzw.: wie aufwendig würde das?

Hängt von deinem Cloudanbieter ab. Wenn der Postgres mit PostGIS anbietet, dann brauchst du da nur die Verbindungsdaten angeben, und fertig. Heroku kann etwa Postgres, wie das woanders aussieht, naja, unterschiedlich. Wobei Postgres auch recht populär ist.

Py-Paul hat geschrieben:Um das etwas auzudehnen: Wie sieht es mit NoSQL DBs aus? wäre dabei der Wechsel unproblematischer (da diese ja angeblich problemlos in der Cloud laufen)? Aber da stößt man ja wieder auf das Problem, dass Django keine NoSQL-DBs unterstützt (und Django nonrel wohl auch nicht so richtig vorankommt).... :-/

Die einzige NoSQL-DB mit Geo-Erweiterungen die ich kenne ist MongoDB. Aber damit wirst du mit Django nicht sonderlich glücklich.

Py-Paul hat geschrieben:[Anmerkung: ein paar Sachen überschneiden sich mit dem Post vorher; Forensoftware sieht leider kein "Sammeln von Zitaten" vor]

Dafür kann man Copy & Paste nutzen, so wie ich das gerade tue

Py-Paul hat geschrieben:

Leonidas hat geschrieben:

Py-Paul hat geschrieben:2) Wie bringe ich das Ganze in Verbindung mit einem der gängigen Web-Kartendienste, also Google Maps oder Bing Maps oder Openstreetmap?

Willst du die Sachen dort eintragen? Oder willst du die Informationen selbst in deiner Datenbank speichern? Für ersteres brauchst du GeoDjango natürlich nicht.

Ja, das ist der Punkt, wo ich mir unsicher bin, siehe oben. Es stellt sich die Frage, ob es nicht sinnvoller, da wesentlich einfacher wäre, zumindest anfangs alles über den jeweiligen Kartendienst abzuwickeln.

Wenn die Kartendienste die von dir gewünschte Funktionalität unterstützen, klar. Musst halt mal in die Dokumentation der jeweiligen Dienste schauen, was sie bereitstellen.

Hallo,

Leonidas hat geschrieben: GeoDjango-Tutorial ist doch schonmal ein guter Anfang.

Das ist schon sehr spezifisch; ich meinte eher Übersichtsartikel, die das Ganze (dann etwas oberflächlicher) abdecken, also inkl. der Kartendienste, Google API, etc. Ich möchte mich erstmal orientieren, in welche Richtung ich grob gehen soll :K

Leonidas hat geschrieben:

Py-Paul hat geschrieben:OK... ich habe da leider einen Knoten im Hirn... Kann ich dann nicht die Suchanfragen über die jeweiligen Kartenanbieter laufen lassen? Hmmm... die Antwort müsste offensichtlich "Ja" lauten, aber irgendwas stört mich dabei... was habe ich da übersehen? :K

Das geht, wenn die Kartenanbieter deine Buden aufnehmen (sind ja nicht dazu verpflichtet) und so eine API bereitstellen. Ob sie so etwas tun ist halt die Frage.

Hmmm... so richtig blicke ich bei der Google Maps API nicht durch...
Wäre schön, wenn da jemand was zu sagen könnte.... ist ja schließlich auch wahrscheinlich in Python programmiert

Leonidas hat geschrieben:Docker ist für Entwicklung gedacht, dass du dir Container lokal auf dem Rechner startest und dort deine Entwicklung machst. Ich finde für den Anfang ist dieses Cloud-Zeug eher schwerer zu verstehen als eine "normale" Installation auf einem vServer. Was du suchst ist eventuell Heruko, aber das ist, meiner Meinung nach alles andere als günstig.

In meiner derzeitigen Desorientierung habe ich Dockers lediglich als Nachfolger von dotcloud gehalten. Dockers ist wohl, wie Leonidas schreibt, der Softwarecontainer und dotcloud bietet den PaaS. Aber dotcloud heißt jetzt auch dockers... Arrrrggggghhhhh...

So, und manchmal hilft Googeln ja auch wirklich. Hier ist ein gerade entdeckter, hoffentlich interessanter Artikel zum Thema PaaS bakeoff: Comparing Stackato, OpenShift, Dotcloud and Heroku for Django hosting and deployment, von einem Mitglied der Boston Django User Group (um nochmal zu beweisen, wie sehr dies hier ins Forum passt ).

Ich habe einfach die Hoffnung hiermit eine letztlich einfachere Lösung als auf einem konventionellen Server zu finden, siehe vorheriges Posting.

Dies hier zum Thema Skalierbarkeit von PostgreSQL / PostGIS auf dotcloud raubt einem aber schon direkt wieder einen großen Teil davon...
("PostgreSQL and PostGIS: Warning - This service does not scale for High Availability on the dotCloud Platform. Please do not use this service if your application requires High Availability.")

Wie würdet Ihr denn ein Django Projekt mit Geodaten und flexibler Skalierbarkeit anfangen? Vielleicht gibt es ja noch andere Wege...

@Py-Paul: So viel Ahnung wie Du von der Materie zu haben scheinst, würde ich sagen das kann Dir alles eigentlich erst einmal völlig egal sein. Du denkst schon über Skalierbarkeit und hohe Verfügbarkeit eines Systems nach, bei dem Du Dich für eine ganz normale Implementierung auf deinem lokalen Rechner wahrscheinlich mehrere Wochen bis Monate erst einmal in die Grundlagen einarbeiten müsstest.

Und Du vermittelst so ein bisschen das Gefühl als wolltest Du Dich vor diesem Schritt drücken oder ihn zu lange hinaus zögern. Denn das GeoDjango-Tutorial führt zu einer kleinen Anwendung bei der am Ende auch Kartendienste eingebunden werden. Es setzt aber vorraus das man sich mit Django auskennt, also zumindest das Django-Tutorial durchgearbeitet hat. Irgendwann muss man sich mal ganz konkret in so etwas einarbeiten, da reichen oberflächliche Betrachtungen nicht mehr aus.

Ich würde so ein Projekt wohl anfangen in dem ich einfach anfange. Erst einmal lokal auf meinem Laptop. In der nächsten Phase dann bei einem normalen, Python-freundlichen Webhoster. Ich für meinen Teil bei einem „shared hosting”-Dienst, weil ich da schon einen habe der sich eignet. Den könnte man eventuell sogar für die Beta-Test-Phase mit echten Nutzern noch verwenden. Und dann kannst Du auch mal Belastungstests fahren was Deine Anwendung überhaupt an Skalierbarkeit benötigt, also ab wie vielen Benutzern gleichzeitig es überhaupt problematisch wird. Meine Vermutung ist ja, dass wenn diese Zahl erreicht ist, so viel Geld reinkommen müsste, dass man sich Rat von Leuten dazukaufen kann, die Erfahrung mit so etwas haben. Falls nicht, stimmt eventuell das Geschäftsmodell nicht.

Ich stelle jetzt mal die Behauptung in den Raum das Django das Rahmenwerk ist, bei dem Umfang und Community für den Anfänger am besten passt wenn es eine ausgewachsene Webanwendung werden soll. Bei anderen muss man sich das eine oder andere Rad selber erfinden, oder jeweils entscheiden welche Räder von Drittanbietern am besten integriert werden sollten. PostgreSQL mit PostGIS ist ähnlich; das ist *die* klassische, freie DB-Lösung für GIS-Daten. Für die Einbindung von Kartenmaterial lokal im Browser bietet sich OpenLayers als Abstraktion über die verschiedenen Kartendienste an. Damit würde schon einmal viel fest stehen mit dem man sich ganz konkret beschäftigen kann.

Wie sieht das eigentlich mit den absoluten Grundlagen aus? Also Python, HTML+CSS, JavaScript, HTTP beziehunsweise „wie das Netz/Web funktioniert”?

Hallo,

BlackJack hat geschrieben:@Py-Paul: So viel Ahnung wie Du von der Materie zu haben scheinst, würde ich sagen das kann Dir alles eigentlich erst einmal völlig egal sein.

Nein!

BlackJack hat geschrieben:Du denkst schon über Skalierbarkeit und hohe Verfügbarkeit eines Systems nach, bei dem Du Dich für eine ganz normale Implementierung auf deinem lokalen Rechner wahrscheinlich mehrere Wochen bis Monate erst einmal in die Grundlagen einarbeiten müsstest.

Das ist kein Widerspruch.... (damit wir uns nicht missverstehen: das ist eine Erläuterung für Dich und keine Rechtfertigung für mich!)

BlackJack hat geschrieben:Und Du vermittelst so ein bisschen das Gefühl als wolltest Du Dich vor diesem Schritt drücken oder ihn zu lange hinaus zögern.

Jain...
Ich versuche mich kurzzufassen: Über diese wahrscheinlich ungewöhnliche reverse Vorgehensweise bin ich überhaupt erst auf Python und dann Django gestoßen. Sonst wäre ich jetzt höchstwahrscheinlich wie viele andere mit PHP / mySQL zugange und würde vor mich hincoden - mit rel. niedriger Wahrscheinlichkeit auf diese besseren Sachen hier zu treffen! Python bringe ich mir gerade bei und bei den Datenbanken stehe ich noch ganz am Anfang; HTML / CSS habe ich ein paar Kenntnisse. So viel zu Deinen letzten Fragen.

Es scheint sich aber auch (wenigstens aus meiner Sicht) auch bei der Frage Cloud / Nicht-Cloud etc. zu zeigen, dass es sinnvoll ist, den Top-Down-Approach zu benutzen. Ich frage gleichzeitig: Was will ich? (z.B. ein gutes Webframework nutzen, das aber ohne viel Installationsgedöhns und Administartionsaufwand, aber gleichzeitig zuverlässig laufend und gerne gut skalierend) und Welche Möglichkeiten gibt es? , womit ich erstmal bei den grundsätzlichen Techniken (konventioneller Server vs. Cloud) lande. Dann sehe ich das einige Clouddienste meinen Wünschen zumindest nahekommen und folge dem weiter. So mache ich das- und Du?

Und ja, ich werde sicher auch Hilfe benötigen- wer sich angesprochen fühlt, ist herzlich eingeladen



Aber:

BlackJack hat geschrieben:Denn das GeoDjango-Tutorial führt zu einer kleinen Anwendung bei der am Ende auch Kartendienste eingebunden werden. Es setzt aber vorraus das man sich mit Django auskennt, also zumindest das Django-Tutorial durchgearbeitet hat. Irgendwann muss man sich mal ganz konkret in so etwas einarbeiten, da reichen oberflächliche Betrachtungen nicht mehr aus.

Hier hast Du völlig recht. Das habe ich auch vor!

BlackJack hat geschrieben:Ich würde so ein Projekt wohl anfangen in dem ich einfach anfange. Erst einmal lokal auf meinem Laptop. In der nächsten Phase dann bei einem normalen, Python-freundlichen Webhoster. Ich für meinen Teil bei einem „shared hosting”-Dienst, weil ich da schon einen habe der sich eignet. Den könnte man eventuell sogar für die Beta-Test-Phase mit echten Nutzern noch verwenden. Und dann kannst Du auch mal Belastungstests fahren was Deine Anwendung überhaupt an Skalierbarkeit benötigt, also ab wie vielen Benutzern gleichzeitig es überhaupt problematisch wird. Meine Vermutung ist ja, dass wenn diese Zahl erreicht ist, so viel Geld reinkommen müsste, dass man sich Rat von Leuten dazukaufen kann, die Erfahrung mit so etwas haben. Falls nicht, stimmt eventuell das Geschäftsmodell nicht.

Ja, darüber habe ich mir auch schon viele Gedanken gemacht. Nochmals: Wäre ich vor einiger Zeit "einfach angefangen", dann würde ich jetzt PHP-Code in die Tastatur hacken. Zum Glück bin ich immer etwas auf Abstand geblieben Es gibt Entwickler, die mir schon von sich aus vorgeschlagen haben, den Kram schnell in der Cloud zu entwickeln (konkret sogar Goggle App Engine).

BlackJack hat geschrieben:Ich stelle jetzt mal die Behauptung in den Raum das Django das Rahmenwerk ist, bei dem Umfang und Community für den Anfänger am besten passt wenn es eine ausgewachsene Webanwendung werden soll. Bei anderen muss man sich das eine oder andere Rad selber erfinden, oder jeweils entscheiden welche Räder von Drittanbietern am besten integriert werden sollten. PostgreSQL mit PostGIS ist ähnlich; das ist *die* klassische, freie DB-Lösung für GIS-Daten.

OK, die Bestätigung ist viel wert

BlackJack hat geschrieben:Für die Einbindung von Kartenmaterial lokal im Browser bietet sich OpenLayers als Abstraktion über die verschiedenen Kartendienste an. Damit würde schon einmal viel fest stehen mit dem man sich ganz konkret beschäftigen kann.

Das kenne ich nicht, werd's mir aber angucken.

BlackJack hat geschrieben:Wie sieht das eigentlich mit den absoluten Grundlagen aus? Also Python, HTML+CSS, JavaScript, HTTP beziehunsweise „wie das Netz/Web funktioniert”?

Python bringe ich mir gerade bei (mit Zed A. Shaw's Tutorial "Learn Python The Hard Way"), HTML / CSS Grundkenntnisse; JavaScript fast gleich Null; Netz/Web allgemein ISO/OSI Schichtenmodell, Apache Webserver: ein bisschen...

Hallo,

Leonidas hat geschrieben: Die einzige NoSQL-DB mit Geo-Erweiterungen die ich kenne ist MongoDB. Aber damit wirst du mit Django nicht sonderlich glücklich.

Für CouchDB gibt es eine Erweiterung namens "Geocouch" (https://github.com/couchbase/geocouch/), die dies Funktionalität nachrüstet. AFAIK hat Iris Couch das auch standardmäßig aktiviert.

Wobei CouchDB + Django ebenso wie MongoDB + Django nicht unbedingt ein Dream-Team ist

Gruß, noisefloor

@Py-Paul: Ich denke schon Du setzt in der Planung eine Ebene zu hoch an. Selbst wenn Du Dir jetzt schon Gedanken über Skalierbarkeit machst, wird das ziemlich sicher im ersten Anlauf nichts werden, wenn man fast von Null anfängt. Das fällt für mich in die Kategorie „premature optimization”. Du weisst weder ob Du Dir darüber *überhaupt* Gedanken machen musst, noch wo der Flaschenhals der noch gar nicht existierenden Anwendung liegen wird. Das sind Sachen die man nur durch Messungen am laufenden Programm tatsächlich feststellen kann. Und ahnen wo Problemzonen liegen werden kann man auch nur wenn man selbst Erfahrungen mit einem System gemacht hat, welches ähnliche Charateristika aufweist.

Top-Down-Ansatz bei der Planung ist eine gute Idee. Bei den grundsätzlichen Techniken konventioneller Server vs. Cloud habe ich erst einmal das Problem das ich weiss was ein konventioneller Server ist, und das ich auf meinem Laptop zum Entwickeln in der Regel lokal alles laufen lassen kann was dann auch auf dem Server zum Einsatz kommt. Nun zum Problem: „die” Cloud gibt es nicht, sondern verschiedene Platformen von denen sich einige deutlich weniger wie ein „normales” System verhalten. Was ich grundsätzlich erst einmal nicht haben möchte. Cloud mag ja ganz nett sein, aber ich möchte das auch auf einen konventionellen Server migrieren können. Insbesondere würde ich mich ungern von einem bestimmten Anbieter abhängig machen.

Und damit ist die Frage Cloud für mich erst einmal irrelevant. Wenn der Cloud-Anbieter VMs oder „Container” mit Datenbanken und Linux zur Verfügung stellt, dann kann ich auf dem lokalen Rechner und einem normalen Server/VServer/Shared Hosting entwickeln und testen und das später immer noch zum Cloud-Anbieter migrieren wenn das irgendwelche Vorteile bringt.