Module reorganization

[Rowlando13]

Bottom Line (updated as we discuss): We should consider reorganization while we are still in the early stages. I don't have any super strong opinions since I had not worked with the library very long, but I am starting to run into some issues with documentation regarding the levels of nesting.

Questions:

• Do people have strong onions on max line lengths for py file?
  Ed - I think they start to get unwieldy in the 500-100 line range.

Future Proofing points (a place for each):

• Hidden Markov model matching,
• interfaces for Vahalla map matching,
• loading trace from gpx files
• supporting other OSM networks besides drive

Downsides of very nest structure

• Long imports(5 levels) eg from mappymatch.maps.nx.readers.osm_readers import read_osm_nxmap

Upsides

• Small files make expansions easier

Current Structure (count in lines)
constructs
---coordinate (62)
---geofence (31)
---match (25)
---road (17)
---trace (284)
maps
---nx
------readers
---------osm_readers (156)
------nx_map (215)
---map_interface (56)
matchers
---lcss
------constructs (211)
------lcss (166)
------ops (287)
------utils (124)
---line_snap (38)
---matcher_interface (33)
---osrm (117)
utils
---crs (4)
---exceptions (6)
---geo (95)
---geohash (154)
---plot (207)
---process_trace (66)
---url (22)

Proposed Structure
?

[Rowlando13]

@nreinicke @jhoshiko @jakeholden @machallboyd thoughts?

[nreinicke]

Some quick thoughts. My personal opinion is that I don't really mind having a nested structure with many smaller files. We could always collect common imports into the root init.py file so users could do something like:

import mappymatch as mm

trace = mm.trace_from_csv("file.csv")
geofence = mm.geofence_from_trace(trace, padding=1e3)
road_map = mm.read_osm_nxmap(geofence)
matcher = mm.LCSSMatcher(road_map)

I do agree that it makes sense to split up files when they start getting longer (100 lines feels okay, 500 lines feels too long). For example, the trace.py file could start to get unwieldy with additional reader and writer methods, could be good to break those up.

[Rowlando13]

I was thinking about the same thing for the init.py file to make the imports nicer which solves the long import issues. I find that having an intuitive and not very nested import structure can really speed up the learning curve because you are not wasting time looking for import statements.

[machallboyd]

I'm fine with the 88-character line limit that black enforces.