TransforMap via CHEST as federated map aggregator for alternative economies and social innovation

(Josef Kreitmayer) #1

@alabaeye thank you so much for that image, it is sooo inspiring!!!

we just had a conversation with @toka about it.

(germanspeaking, sorry:

TransforMap and MMM
(Josef Kreitmayer) #2

@alabaeye do you think, you could invite someone from that mapping project to the discourse?

It would be great to find out, how much effort is behind the project, from each partner, and from their side.

(Adrien Labaeye) #3

Glad that has resonance.

Would be great to have a thread on discourse for that discussion with main points summarized in English…

I had tried to find someone, but didn’t. Could try again. There is this page already existing to discuss that particular map: Wir bleiben alle (convergence/mash-up Map in Berlin)

Generally, I’m not sure this thread is well define. Could you specify what you want to see discussed here? If it’s about the general architecture of TransforMap, I would suggest staying under TransforMap and MMM or find an appropriate thread under engineering. I believe we need to strive integrating the discussions to reach alignement on this core issue that is in the end related to what we want TransforMap to be. :smile:


(Josef Kreitmayer) #4

@alabaeye I would like to first get some idea how @almereyda thinks about the topic, before streaming it into the general public stream.

I know, that he already had some thoughts on architecture, and is currently not involved in this discussion, that was started yesterday by @species, @toka and me.

A mayor idea, that I see is, that we need that aggregation (read) anyway, before we even can think about interoperability (write), and it would be a great first product (so to say), that we can involve the partners with, and already get a taste.

As @species pointed out yesterday, the outcome will be impressive, but at the same time, if you activate all the filters (community layers) at the same time, just a mess. Some partners will be happy with that, as they do not want to invest more energy, some others will want to further develop towards interoperability.

(Adrien Labaeye) #5

I don’t understand that. This thread is already public. Do you mean you tried to hide it in a category where people wouldn’t stumble upon it?

This is very much my thinking! I think this is the first thing we need. Then activists from our communities can understand the whole logic and get involved in the governance (i.e. what maps should be displayed on that aggregator). And we can engage the interoperability process (write).

[quote=“josefkreitmayer, post:4, topic:809”]
but at the same time, if you activate all the filters (community layers) at the same time, just a mess.
[/quote] Yes sure. But a mess is a good start. :wink: So communities see the challenges and don’t think that’s an easy task…

(Josef Kreitmayer) #6

fully agree @alabaeye,
wold like to hear the voice of @almereyda.

yes : )
if someone stubles upon it, that is fine, I just did not want to put it in a thread with already many contributors before talking more intimate about it. If someone joins by coincidence, that is fine.

(Adrien Labaeye) #7

I’m not so sure I like that. We’re creating more complexity and this is an important discussion in particular for the communities we want to involve. I would like to have this discussion in full light, independently from @almereyda’s point of view.

(Thomas Kalka) #8

So what exactly is the question in this thread, which we than can propagate to

(Josef Kreitmayer) #9

translating some of a conversation in the first post, between @toka @species and @josefkreitmayer about a federated system and data aggregation via the ETL. I think, there is also another post about the aggregation of the data as in the hardcoded example of but I currently can´t find it, and just managed to find that conversation excerpt below:

Proposal of Thomas: User Story: create the foundation for a federative agreement

  • TransforMap creates (as a first step in CHEST e.g.) an accumulation layer
  • TransforMap should be designed as a federal structure so that the partners host their data themselves which gets aggregated.
  • TransforMap is a federal node and not responsible to keep the data active, or to maintain.
  • If partners can register and mentain points in their systems, they should remain responsible.
  • If we are not purely mapped in OSM, but accumulate in a separate layer, then it does not matter if there are duplicates. We want to first time see the full range of alternatives if something is twice that does not harm anything. In OSM that would be an absolute no-go.
  • Duplicates are not only a problem at OSM. If e.g. there are 5 different pages that use one and the same object and we purely mapped in OSM, we have not solved the problem of duplicates.
  • If we do not oriented to OSM, then everyone has their own view of the world represent, if we take OSM, then we must orient towards its perspectives.

User Story UUID identifier

  • UUID identifier linking should be a goal.

Consensus: we primarily want a federal system
For Thomas, federalism would mean to actively invite, people to host their own data.
Discussion here is seen as relevant TransforMap and MMM

Three main streams into the TransforMap ecosystem:

  1. Editor, into the Transformap Database (Map Editor), to allow people to map independently (the main motivation for many contributors), and also create their own filtersets (FIDETO) and map visualizations (Map Viewer)
    Editor is still an open question to approach.

  2. ETL aggregate datasets, which are already there and mentained with the respective partners (ETL)

Aggregation goes first,

    • Aggregation is read and display on aggregations-layer
    • Iteroperabilität is aimed very high (very likely too high for the ressources given).
    • Interoperability is allow to write upstream to the datasource.
    • Conclusion: Concentration on Aggregation Layer display.

3.bulk import datasets which are no longer maintained (Bulk import into Transformap Database)

Mapping as a commons (manifesto)