Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Split providers into protocols, formatters and symbolizers #695

Closed
2 of 8 tasks
Jeremy-Gaillard opened this issue Mar 26, 2018 · 1 comment
Closed
2 of 8 tasks

Split providers into protocols, formatters and symbolizers #695

Jeremy-Gaillard opened this issue Mar 26, 2018 · 1 comment

Comments

@Jeremy-Gaillard
Copy link
Contributor

Jeremy-Gaillard commented Mar 26, 2018

Follow up to this comment.

Providers are presently in charge of handling a protocol, as well as generating and styling geometries.

These tasks should be split in several modules to improve factorisation:

  • Providers: they fetch data following a specific protocol
  • Formatters: they transform the raw data given by the providers into a generic TypedArray (when possible)
  • Symbolizers: they create Three.js objects from the generic TypedArrays and styling rules

TODO list:

  • Move and rename JS files in charge of formatting into a Parser directory
  • Homogeneize the interface of parsers to a single static function : parse(file, options) -> promise
  • Move formatting and symbolizing code out of providers
  • Move symbolizing code out of formatters
  • Create a generic symbolizer module supporting:
mbredif added a commit that referenced this issue Mar 26, 2018
Multiple classes are in charge of decoding file chunks. They were scattered into multiple directories and had different names : Loaders, Parsers, IoDrivers...
They are now all moved to a new src/Parser directory
This commit addresses first item of #695
mbredif added a commit that referenced this issue Mar 26, 2018
Multiple classes are in charge of decoding file chunks. They were scattered into multiple directories and had different names : Loaders, Parsers, IoDrivers...
They are now all moved to a new src/Parser directory
This commit addresses first item of #695
mbredif added a commit that referenced this issue Mar 26, 2018
Multiple classes are in charge of decoding file chunks. They were scattered into multiple directories and had different names : Loaders, Parsers, IoDrivers...
They are now all moved to a new src/Parser directory
This commit addresses first item of #695
mbredif added a commit that referenced this issue Mar 26, 2018
Multiple classes are in charge of decoding file chunks. They were scattered into multiple directories and had different names : Loaders, Parsers, IoDrivers...
They are now all moved to a new src/Parser directory
This commit addresses first item of #695
peppsac pushed a commit that referenced this issue Mar 27, 2018
Multiple classes are in charge of decoding file chunks. They were scattered into multiple directories and had different names : Loaders, Parsers, IoDrivers...
They are now all moved to a new src/Parser directory
This commit addresses first item of #695
@mbredif mbredif mentioned this issue Apr 4, 2018
@gchoqueux
Copy link
Contributor

Now the itowns architecture is

  • Layer to add data on viewer, with process to update data.
  • Source to define data access
  • the chain fetch/parse/convert to provide data to viewer

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants