Clemens walks us through https://github.com/cportele/route/
George: how do you construct the actual route? its a sequence of endpoints
Clemens turns to route on map
Clemens: initially the segments were line string between points, can be redundant and simplified to ease transmission
George: the overall path is a sequence of linear elements
Clemens: yes
George: could also be complex geometry
Clemens: yes, typically you go
without interruption between start and end but could be more
complex
... for multi-modal you will want to separate out the different
segments
George: this approach allows for various more complex
Clemens: easier usually to use linear, depending on precision and accuracy requirements you can use the more complex geometries
Ted: simpler too when just taking rail. in-between if taking a taxi/uber avoid scenic route, passenger safety
Mark: I like this contribution,
the UML, textual description and GeoJSON
... can you tell me more about GeoJSON?
Clemens: the route overview we
say is a GeoJSON object [displacing JSON]
... key thing to being Geo is the geometry, strings
representing lines, polygons...
... also coordinate, point geemetry. it is basically a few
conventions with simple structure that are very widely
implemented
... event Github recognizes it and draws it on a map
... everyone very quickly was able to do something with it.
Geometry is an extension for people to use easily in various
libraries
Mark: any further
questions?
... Ken, have you deposited any use cases?
Ken: only what was in the templates. reviewed with Megan one from TC204 on phone
Megan: this is an extended
version what we discussed at the previous meeting
... demographic and current state of city provides a starting
point for simulation. different models for changes in housing,
job markets, other influences
... travel simulations for extending subway lines, land use and
housing value impact
... key actors are policy makers, city planners and
researchers
Megan reviews https://github.com/w3c/tocc/blob/master/use_cases/RoutingUseCases_Presentation_25Mar2019.pdf
George: thinking of what you just
did for transportation planning compared to Clemens' approach
which is more turn by turn
... you'd want traffic congestion, various other point
information
Clemens: in the routing pilot we
didn't need access to underlying graph structure of transport
network but in the vehice route planning space would be useful
for simulations
... I am taking more an end user use case whereas your is more
higher level, business process
Mark: there has to be a more detailed information about alternative routings and not just the one taken, different modes, roads used
George: simulation would need a composited model
Mark: this is large scale agent
based travel simulation planning
... most conceptualize that as agent actually making decisions
going from A to B. we want to get interaction between agents to
model congenstion handling
... trip from A to B to ... is not typically viewed as
inter-agent interaction
Megan: agents are not so much interacting as responding to situations
George: I see various parts of what you're looking for can be handled in GeoJSON
Mark: what are the shared classes
that exist between these two use cases. what are the different
perspectives on property level interesting to see
... question: how to make these shareable
Clemens: my interest as well,
route ontology in GeoJSON is mapable
... in pilot I described, some of the complexity of the
underlying structure is is hidden in the API
Ken: I did do some research on
what we've done for routing in ITS
... traffic management data dictionary, handling events
(parade, accident, evacuation order...)
... in tecm2 structure, used for providing traveler
information
[Ken displays]
@@link
Ken: there are quite a few
similarities, I do find it interesting the different levels of
detail provided
... traffic management system didn't include vehicle
restrictions, focus not in sending all the information about
the route
... they provide high level routing information and link to
more detailed if needed
... the data model being used for these communications is not
our concern, we are working at the ontological level
Mark: classes and properties we
identify needed to be mapped to underlying sources
... it becomes problematic in the many variances
[physical model traceability focus]
[showing mappings and calculation processing]
Mark: what we should include in
our effort at some point is [data] mapping methods
... looking forward to getting your input
Ken: you start your tracing typically from the underlying physical model
Mark: how to move forward?
... how do we identify the points of intersection between these
use cases?
... in our next meeting we can discuss what it means to be in a
shared conceptualization
Clemens: we can make something practical to move forward
Megan: how will we represent this? I can approximate the relevent bits in UML or put routing model in OWL
Clemens: if it helps I can do that step and create a Turtle version
Mark: UML good for planning use case for visual representation
Megan: agree and then when we look at the relationships will need that
Clemens: graphic helps, define relationships between resources
Mark: agree, reason to go UML - the visualization can be both illuminating and obfuscating complexities we will need to figure out
Ken: UML is a very broad term, I would suggest we use ODM (Ontological Data Model?) class diagrams for how you represent an ontology and can be converted to OWL
Clemens: I used TC211 version and can try to convert
Ken: I'll send an example
Mark: just making it to the OWL piece of ODN
Megan: what is on Ken's screen isn't that scary
Mark: it reads more like a
diagraming approach than logic representations, think we want
something simple on class relationships
... diagram you have may be what we want in the short term
Clemens contributes to argument against UML
Mark steers discussion back to high level and where we should focus
Clemens: perhaps I can start off with reducing some of the details I have
Mark agrees to level needed for where we are in discussion
Mark: action item is to identify
intersection between these use cases. Megan will construct a
view she has for model and Clemens view from his
... suggest the two of them meet independently to review
... acceptable?
[agreement]
group to reconvene after
Mark: let's schedule for two
weeks out
... possible?
Megan: sure, given level of detail for next round
Clemens: should be fine
8EST/14CET April 29, Wednesday
TC204 WG1 on 14th @4pm EST
Ken: follow through in getting WG to use this template has been an issue
Mark: very useful metadata about the use cases
Ken: within scenario you can put in your flows. format similar to what SAE does
[display of SAE template and comparison]
Ken: I know the SAE one is being
used by various external projects
... happy with any one of three template models
Mark: which is fastest to pickup and use?
Ken: SAE like model perhaps
... I'll update my current markdown and put what should be
there
... adding some ISO 204. I'll let everyone know which I propose
to omit
Mark: great
... any other comments?
... any additional business?