Comments (12)
Way to go, Robin!
More realistically, simple features do not represent networks, so creating, managing and analyzing networks still remains to be done. An advantage would be that you can constrain to LINESTRING
s between nodes, this is something sp cannot do - it only represents MULTILINESTRING
s (which, of course, can be of length 1 - this is the current splanr approach IIRC).
from stplanr.
Thanks for that - yes limiting it to LINESTRINGS
will have advantages and creates a good basis for classes representing roads etc if we want to go that way (not sure we do...). One to think about anyway...
from stplanr.
I was thinking about this the other day. Networks are clearly important I think.
If we're adopting sf then we could potentially use the PostGIS topology model (that converts simple features into topologies) in some way.
from stplanr.
GDAL has GNM; is that useful? Does it connect to the PostGIS topology model?
from stplanr.
I hadn't seen GNM before. It seems a driver could be written to connect GNM to PostGIS. GNM may be the more appropriate choice though as sf uses GDAL.
Is GNM consistent with the structure of sf?
from stplanr.
I haven't looked into that; my assumption is that edges will be features, but a network must consist of nodes, edges, and their graph/topology.
from stplanr.
Yes, I agree that it would be most likely for edges to be features. I suppose you could add additional columns to represent the connecting nodes (anode, bnode). It would then need additional functions to calculate shortest paths, identify weights (could be yet another column), etc.
from stplanr.
Suggested policy: implement all new features that are easily implementable with sf in sf then add an argument sf_out = FALSE
which means we'll return an sp object by default unless the user specify otherwise. That way:
- We don't force people to use these strange things called simple features until they're good and ready (and the package is ready for the prime time).
- We get to learn sf Wahey.
- The user gets faster code :)
What do you reckon to this @richardellison?
@edzer are there any issues you know of with setting sf as an import? I.e. is it a pain to install on some computers?
Possible knock-on benefit: will increase knowledge of this new paradigm for spatial data in R and encourage people to upgrade their GDAL version!
from stplanr.
The MacOS ports are not yet on CRAN, meaning install.packages("sf")
will not work there (Simon Urbanek's build farm is still at gdal 1.11)
from stplanr.
Ah OK, makes sense for that to get sorted then I guess. Ta 4 the info.
from stplanr.
Sounds reasonable but we should wait for MacOS ports unless there is a way of only optionally including it? In other words, check if sf is installed (or available on CRAN) and if not use sp only.
from stplanr.
Agreed. Good discussion. Closing for now and keep an eye open for sf Mac ports!
from stplanr.
Related Issues (20)
- Make `line_segment()` vectorised HOT 1
- Docs updating slow? HOT 2
- Add arguments to rnet_merge() preventing sideroads getting values of main roads HOT 3
- Speed-up `rnet_merge()` HOT 29
- GitHub actions failing
- Comparing the results between angle_diff with calculate_angle/get_vector HOT 1
- Error message in bind_sf
- CRAN issues
- bug in the rnet_merge function when defining the funs HOT 3
- Use different buffer options in `rnet_merge()`
- Convert large GeoJSON file to PMTiles HOT 1
- bug in geo_buffer HOT 7
- Possible speed enhancement to `mats2line()` HOT 3
- Invalid LineStrings in routes_fast_sf HOT 1
- Use `od::odc_to_sfc()` do the legwork in `mats2line()` HOT 3
- Bug in `line_segment()` when using certain values on projected data with `rsgeo` implementation HOT 8
- `rnet_merge()` fails when inputs are projected HOT 4
- `line_bearing()` is slow HOT 3
- Argument of segment_length in line_segment fun causes issue HOT 14
- Tried creating a route from desirelines using osrm function HOT 9
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from stplanr.