Platform development progress and feedback!


To the Ojuso community,

I’ll be working on the Ojuso platform with Leo over the next weeks and months. This topic should ideally serve as the main thread to update you all on our progress so please keep checking back over time.

As Ojuso is a community project, we certainly welcome as many questions and as much feedback as you can muster! :hugging: Let’s start this project with a bang! :fireworks:

Livvy :heart:

Form to input new cases

Update 1: Mapping application in development will be happening over at . Please forgive the crude deployment thus far - this will be patched up ASAP so / redirects to /beta


Update 2: Translation service has been launched over at - this will be where the Ojuso community can help translate the mapping application. This will likely be moved to in the very near future so bear in mind that things may change or break over the next few days. :grinning: Hopefully I’ll have this integrated with the map as I work on i18n (internationalization). :blush:

pinned #4


Update 3: CAS Single Sign-On Server is now in the process of being forked with customized branding / deployment configuration. This will go though a process of being tested and then will be integrated with this Discourse forum - this should hopefully happen as transparently as possible (account data will be migrated to another backend) and you should hopefully be able to sign in with the same credentials but just via a different global sign-on page. This is dubbed the “Ojuso Identity” - feel free to come up with better name suggestions! :blush:


Update 4: Just figuring out how to migrate the password database to Django which will provide the new account backend for the CAS server. The hashing algorithms of Discourse and Django both are set to use PBKDF2-SHA256 but they have a different number of iterations. Even if I set the number of iterations in Django to equal 64000 (the same as Discourse) i’m still unable to produce an identical hash - maybe the implementation is different? :expressionless:


Update 5: CAS server is integrated with Django and deployed. The next step is to integrate all of the Ojuso services and also to brand the login page - this will be done later as I’m going to put all of the focus on developing the map application now - you should see some big changes happening soon! Keep checking back :tada:


Update 6: Reminder of the services so far:

Map: AKA Ojuso Platform
Translation Service:


For later:
Polygons or territorial shapefiles would need to be available as a separate layer. This won’t be available in the first iteration of the platform. shp2pgsql
Co-ordinate Reference System would have to be known by the person adding the case study.


Notes for importing shapefiles

Importing shapefile

Shapefiles can be imported into a Python-like object with LayerMapping utility and then saved to an appropriate GeoDjango model in the database. This avoids the need to make SQL queries directly to the PostGIS database.

>>> from django.contrib.gis.utils import LayerMapping
>>> from geoapp.models import TestGeo
>>> mapping = {'name' : 'str', # The 'name' model field maps to the 'str' layer field.
               'poly' : 'POLYGON', # For geometry fields use OGC name.
              } # The mapping is a dictionary
>>> lm = LayerMapping(TestGeo, 'test_poly.shp', mapping)
>>> # Save the layermap, imports the data.
Saved: Name: 1
Saved: Name: 2
Saved: Name: 3

Rendering on map

GeoDjango supports a GeometryCollection field that can hold a combination of different features. This can then be returned as GeoJSON to Leaflet which can be displayed on the map.


What are peoples thoughts on combining the website with the map? Might make usability between the two a little easier as you can easily manipulate links from Map -> Website and Website -> Map. Also the markup between the two can be shared for a consistent brand / feel.


I think that sounds good. I’m sort of wondering about things like font - whether we can use Noto Sans across the platform, or whether that’s really difficult?

In terms of the website and map being one and the same, I have no idea. Do you mean taking the off WordPress or something? I don’t think I quite understand!


Thought this might be of interest:

Charter for Building a Data Commons for a Free, Fair and Sustainable Future



This Charter/Carta provides practical guidance and political orientation for mapping, modeling, managing and sharing data as a Commons. If you follow these guidlines, you will contribute to a Global Data Commons. That is, you will govern your mapping community and manage data differently than people who centralize data control for profit.

The Charter does not describe the vision, scope or values of a specific mapping project, but Data Commons principles. It will help you reimagine how you protect the animating spirit of your mapping project and prevents your data from being co-opted or enclosed.

The Charter as a whole is the maximum „commons denominator“ of mapping projects that aspire to share data for the common good.

Help commonize maps and data! For the people, by the people.


  1. Reflect on your intentions together
    Discuss the core of your project again and again. Everybody involved should always feel in resonance with the direction in which it’s heading.

  2. Make your community thrive
    For the project to be successful, a reliable community is more important than anything else. Care for those.

  3. Separate commons and commerce
    Mapping for the commons is different from producing services or products to compete on the map-market. Make sure you don’t feed power-imbalances or profit-driven agendas and learn how to systematically separate commons from commerce.

  4. Design for interoperability
    Think of your map as a node in a network of many maps. Talk with other contributors to the Data Commons to find out if you can use the same data model, licence and approach to mapping.

  5. Care for a living vocabulary
    Vocabularies as entry points to complex social worlds are always incomplete. Learn from other mappers’ vocabularies. Make sure your vocabulary can be adjusted. Make it explicit and publish it openly, so that others can learn from it too.

  6. Document transparently
    Sharing your working process, learnings and failures allow others to replicate, join and contribute. Don’t leave documentation for after. Do it often and make it understandable. Use technologies designed for open cooperation.

  7. Crowdsource what you can
    Sustain your project whenever possible with money, time, knowledge, storing space, hardware or monitoring from your community or public support. Stay independent!

  8. Use FLOSS tools
    It gives you the freedom to further develop your own project and software according to your needs. And it enables you to contribute to the development of these tools.

  9. Build upon the open web platform
    Open web standards ensure your map, its data and associated applications cannot be enclosed and are prepared for later remixing and integration with other sources.

  10. Own your data
    In the short run, it seems to be a nightmare to refrain from importing or copying what you are not legally entitled to. In the long run, it is the only way to prevent you from being sued or your data being enclosed. Ban Google.

  11. Protect your data
    To own your data is important, but not enough. Make sure nobody dumps your data back into the world of marketization and enclosures. Use appropriate licenses to protect your collective work!

  12. Archive your project
    When it doesn’t work anymore for you, others still might want to build on it in the future.

How to? Recommendations

NOTE: Each paragraph/principle of the Charter is supposed to be fleshed out via some “how to” recommendations. The following lines are only remnants of former conversations, not yet to be considered a draft of the HOW TO. The idea is to add a HOW TO in such a way, that everybody can easily understand how to implement a principle in his/her project.

Link to WikiData and OpenStreetMap
Don’t maintain your single data set. Contribute as much as possible to already existing data commons. Make them thrive.

Start from Semantic Modelling
Semantic modelling is very powerful, make use of it. Remember: everything derives from your data modelling protocol.

Make data claims traceable
Include/reference data sources. Especially when mapping controversies, include links to organizations and agencies addressing related issues.

Advance people’s needs
There are plenty of fair and sustainable ways to meet people’s needs. To focus on needs eases collaboration and ensures

Self-host your infrastructure
To enable both, collaboration and autonomy, choose technology which allows to be replicated quickly, and enables you to easily iterate and improve your map.


In terms of the website and map being one and the same, I have no idea. Do you mean taking the off WordPress or something? I don’t think I quite understand!

Yep basically the website would become part of the map site. Could still have the same content but would mean we don’t have to maintain Wordpress.

They also have a software demo but the performance is terrible!

Perhaps Wordpress is the more familiar option though.


I guess generally we are already using Wordpress on other things and so I think it makes a lot of sense for us to stick to that.


Ok, no problem. It’s totally up to you :+1:

I really the points you link to. Could this be something our project adopts? Could be a separate thread tbh.


I think it may be helpful for me to actually explain the reasons for considering keeping the website within the Django framework as on face value it may seem rather pointless.

Currently, there isn’t really any markup created for the Ojuso website. This is essentially the layout and appearance of pages - including the typography, padding, margins, colours and so on. Because the map project requires a degree of this during the front end development, I thought it might make sense to try and reuse the same “templates” on the actual Ojuso website and to have links between the website and the map (so people can navigate between the projects).

I completely understand the familiarity of Wordpress when it comes of creating and managing content (usually blog posts) as it provides things like URL slugs, archiving, categorization and also displays the author of the post. I think these issues would be well founded in regards to a blog but less so when it comes to websites. (I don’t believe Wordpress is really necessary for static pages).

I’ve seen many sites using a Wordpress instance simply for blogging (usually at and use a more sensible system for managing the rest of the site. I think we should have a discussion regarding this on Friday if we have time.


Reminder to self: didn’t really have time to discuss this last Friday but still should be talked about at some point.


Below is the scope we originally agreed late May.

Web GIS Funding Proposal and Technical Draft - FINAL_v2.docx (10.1 KB)
Web GIS Funding Proposal and Technical Draft - FINAL_v2.odt (25.5 KB)

@livvy and I are going to have a chat now about the project and how we can restart working together! Plan.


Our mini goals (updated as the previous is out-of date already) from conversation with @livvy:

  1. Letting end user submit Simple Form (excluding file uploads)
  2. Letting end user submit Comprehensive Form (excluding file uploads)
  3. File uploads for both forms (with processing so it can be viewed at various sizes; YouTube/Vimeo API)
  4. Display the case studies in a template (simple on separate pages; maybe look like a wiki but not be editable)
  5. Data sharing with EJAtlas ==> this might be two points for their data and for our data.
  6. Keeping HTML/CSS/markup all within Django framework - taking Wordpress down and transfering the static to within Django
  7. User account and data protection (personal data is theirs but the non-personal info should probably be ojuso’s and not be able to be deleted?)
  8. Single Sign On: functionality to enable users to use all parts of the platform without having to re-enter their login credentials. This may be done by using OpenLDAP to create a single set of login credentials with a layer on top to allow users to move between the forum, map and any other parts of the platform without re-entering their username and passphrase.