Magical java typing for additional attributes

[KasiaKoz]

Mentioned in 'Future Work' of #118 and addition to that branch of work. This PR is a change in addition to #118 and allows the representation of additional attributes in a new, simpler format. (please note the branch of a branch merging request 😬)

Old, long form format:

'attributes': {
        'additional_attrib': {'name': 'additional_attrib', 'class': 'java.lang.String', 'text': 'attrib_value'}
    }

is still allowed, and encouraged when the user wants to be specific about java types of the values.

This PR makes GeNet use simple form attributes:

'attributes': {
        'additional_attrib': 'attrib_value' 
    }

across the board, i.e. when

• reading xml files,
• setting 'simplified' tag for the network
• crs for network and schedule
• reading osm (i.e., when creating network graph from osm, the format of osm tags being saved)
• road pricing osm ID to toll matching

Breaking changes, in some cases

Because genet now represents all additional attributes in simple form, the following possible problems will need to be announced (via new release of genet with changelog).

• In project scripts that search for links with values of specific osm tag values. Example:

links = n.extract_links_on_edge_attributes(
    conditions= {'attributes': {'osm:way:highway': {'text': 'primary'}}},
)

this will break because genet now represents this data in short form, do the way to query it is:

links = n.extract_links_on_edge_attributes(
    conditions= {'attributes': {'osm:way:highway': 'primary'}},
)

Other annoying things

The road pricing functionality in genet that allows OSM ID to toll mappings is affected by this change. The problem is that now the data can be many types. In particular, OSM IDs can be integers (genet's type when reading OSM), float (PT2MATSim network's type via being saved as java.lang.Long) and strings (puma's default when creating network from OSM). This is dealt with via an additional parameter in the offending function, the user needs to be mindful of their data types and set them accordingly to match. This was also noted in the update of the example jupyter notebook for road pricing. All defaults are set to strings which should mean no breaking changes in anyone's current setup.

Please note, this PR includes a complete rerun of many jupyter notebooks and updates to some documentation stored whithin, which I think will make it look a lot bigger than it actually is...

[mfitz]

I've left a handful of minor comments.

I've also left a comment about how a network could be changed purely by the round trip of reading in to GeNet and then writing out without making any modifications (attributes with an original class=java.lang.Long will become class=java.lang.Float), that has raised a flag in my brain. I can't think through the ramifications of this behaviour, but it seems worth trying to get a handle on whether or not this change is important, particularly in terms of the effect on MATSim.

[KasiaKoz]

@mfitz the two biggest things that I tried to address post your review:

• reading comma separated values to sets, did not fix right away as I don't think it's going to cause massive issues at this point in time but logged it: GeNet reads comma separated attributes into sets #125 and https://arupdigital.atlassian.net/browse/LAB-1750
• the Java-python, python-Java functions are not bijective, even more so now that I added the extra java classes. To this effect, I added a flag to force reading matsim networks using the old, long form in case the java types need to be preserved: d019152. This also has an added bonus of backwards compatibility which will be appreciated by owners of current project scripts.

[mfitz]

Looks good!