Skip to content
This repository has been archived by the owner on Feb 8, 2019. It is now read-only.

Autonomy #41

Open
amaury1093 opened this issue Sep 29, 2018 · 6 comments
Open

Autonomy #41

amaury1093 opened this issue Sep 29, 2018 · 6 comments

Comments

@amaury1093
Copy link
Contributor

amaury1093 commented Sep 29, 2018

I want to move the conversation here too, so that it's logged and people can start working on it.

The simplest idea we can implement today is Bapo's slider idea, and I propose we implement this in v1. In parallel, we can think of a more robust and general weighing system for later versions.

More concretely, here are the steps:

  1. Group all the political entity types in this gdoc into 5 or 6 big categories, that will be shown on the same autonomy level. Mappers can help here.
  2. Add a query parameter in the url ?autonomy=2 to retrieve only territories that are in that autonomy level. Should be intelligent enough to find the next autonomy's political entities if some parts of the map are not covered by higher autonomy entities.

image

@amaury1093 amaury1093 added this to the v1.0 milestone Sep 29, 2018
@amaury1093 amaury1093 added this to To do in ChronoScio v1.0 via automation Sep 29, 2018
@bapo224
Copy link

bapo224 commented Sep 29, 2018

(let me know if this is hard/impossible with the coding side but) the levels should not be only dependent on political entity type but more so on diplomatic relations. For example an independent dukedom will appear on a higher level than one that has sworn fealty to a kingdom.

I think two different approaches we could take to solve this would be the following:
a. render all levels on diplomatic relations (except for armies if we eventually map those, though I assume this won't be an issue for V1).
b. render all levels on political entity type. This would complicate the types as we'd need 'independent x' and 'subject x' as separate political entity types. This would also mean we'll have to manually map out every level in separate shapefiles which would probably be a heavy load for the site.

a is more preferable but b might be an option if we can't figure out how to do a.
Thoughts?

@amaury1093
Copy link
Contributor Author

Right, I was thinking about b in the beginning, but I agree with you, a is a better option.

DiplomaticRelations (annex 2) each have parents and children. So I guess the best way to render this to to decide on which level each parent/child of each DiplomaticRelation will be rendered.

Something like -

Level Renders
1 Military alliance Parent, Codominium Parent
2 Military alliance Child etc

@bapo224 Would this model work?

@bapo224
Copy link

bapo224 commented Oct 1, 2018

Yes I think that will work, but it might be a bit more complicated for example a subject nation that has a subject of his own. That nation would be both client state parent and client state child.

Maybe a third possibility is making the render level a parameter the mappers have to fill in rather than something the site has to figure out?

@amaury1093
Copy link
Contributor Author

amaury1093 commented Oct 1, 2018

I would not recommend a render level parameter inputted by the mappers, because it creates duplicate and inconsistent data. The only thing a mapper should care about is objective data (how is a PoliticalEntity related to another?) rather than functionality (how should this data be rendered?).

I the above table, instead of only having Parent/Child, we could replace by Gen0, Gen1 to represent generations. I'm pretty sure we can figure out something. I can try to create a 1st version tonight, but if you want you can start before.

@quorth0n
Copy link
Contributor

quorth0n commented Oct 1, 2018

the only thing a mapper should care about is objective data rather than functionality

+1

That nation would be both client state parent and client state child

At least on the database level I don't believe this would be a cause for concern, if the frontend is set up to properly handel entities of this type then this should be fine. I do also like Amaury's generation idea, but I'm going to wait for the modeling to comment further.

@quorth0n
Copy link
Contributor

quorth0n commented Oct 9, 2018

@amaurymartiny @bapo224 any updates on this?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
Development

No branches or pull requests

3 participants