I want to create isolines around point locations (public transport nodes) that indicate the service area that can be reached within max. 1 km of walkable distance (with steps of 200 m). When looking at the output, it seems that many of those service areas are not large enough. There are often pieces of road that should be included in the area (as they are within 1 km distance) but they are not. I included a screenshot of one of the service areas below to illustrate.
I this an issue that can be resolved or not?
Illustration
Many thanks
We have to consider the performance of service when calculating the isoline. For this reason, the Isoline service have constraints on the range value.
Please check the below screenshot related to range object and its maximum value.
Related
I have a number of locations between which I want to know the travel time and distance.
The locations have been correctly geocoded. However, the problem I am experiencing is that some of the locations lie between a regular road and a motorway. In fact, they lie closest to the motorway.
In this case, the travel time and distance I receive consider the location to lie on the motorway (the closest road), which leads to an incorrect estimation of the actual travel time and distance.
Given that I cannot manually adapt each geocode to lie closest to the regular road, I need a different solution.
I included 'street!!' in my call as indicated on https://developer.here.com/api-explorer/rest/routing/route-to-location-near-motorway but to no avail.
My call looks like this "https://matrix.route.api.here.com/routing/7.2/calculatematrix.json?start0=x.x,y.y&destination0=street!!x1.x1,y1.y1&mode=fastest;car;traffic:disabled&summaryattributes=traveltime,distance&app_id=...&app_code=...".
Is there another way to avoid that Here puts the destination on the motorway?
Your help would be greatly appreciated. Thank you in advance!
Below you find one example
Geocodes of departure: 51.090995,4.018793
Geocodes of destination: 51.017960,3.694040 (close to E40/A10 in Belgium)
When I use the matrix routing API, I get a distance of 29799 meters and a travel time of 1317 seconds.
My call:
"https://matrix.route.api.here.com/routing/7.2/calculatematrix.json?start0=51.090995,4.018793&destination0=street!!51.017960,3.694040&mode=fastest;car;traffic:disabled&summaryattributes=traveltime,distance&app_id=...&app_code=..."
When I use the routing API to get the directions, I can see that my destination is updated to 51.0187054,3.6935735, which is on the E40/A10. This gives me a distance of 29827 meters and a travel time of 1335 seconds.
I used the call below:
"https://route.api.here.com/routing/7.2/calculateroute.json?app_id=...&app_code=...&waypoint0=51.090995,4.018793&waypoint1=street!!51.017960,3.694040&mode=fastest;car;traffic:disabled"
Given that the distance and travel time differs, I executed my matrix routing API call again with the updated destination geocodes (51.0187054,3.6935735). This provided me with the same distance and travel time as my initial matrix routing request, i.e. 29799 meters and 1317 seconds.
I used this call:
"https://matrix.route.api.here.com/routing/7.2/calculatematrix.json?start0=51.090995,4.018793&destination0=street!!51.0187054,3.6935735&mode=fastest;car;traffic:disabled&summaryattributes=traveltime,distance&app_id=...&app_code=..."
As such, I am sure the destination is on the E40/A10. How can I avoid this?
On a related note, why do the travel time and distance differ between the matrix routing API and the routing API?
When I enter the geocodes in GoogleMaps, I actually get the position I wanted.
As you can see, it is not on the E40. Why can't I get a route to the nearest regular street?
So taking the example you gave, the destination waypoint 51.017960,3.694040 lies very close if not on the E40/A10 itself. See image below:
Moreover, using our reverse geocoder API to get the list of address within 200m radius of the destination waypoint returns only addresses (points) along the E40, 9052 Gent, België with street match level . There is therefore no way for the algorithm to know which nearby street you intend to arrive when the waypoint is many hundreds of metres off. I will suggest to correct your waypoints using our reverse geocoder api to determine which waypoints are way off your intended address.
distance is given in meters for this query:
https://places.cit.api.here.com/places/v1/discover/search?app_id=my-app-id&app_code=my-app-code&at=36.97425,-122.03099&pretty
Is there any plan to support "metricSystem" parameter(as is done in the case of Routing APIs) so that the result can provide distance in miles?
Correct, the distances are just given back in meters from the Places API. There are no further plans to change this in future. But you can easily calculate the values into miles on client side.
We are at a cross roads where we need to decide if we are going to store our GeoSpatial data in DocumentDB or SQL Azure. According to this article, the polygon parameter of the ST_WITHIN function in a query can contain a maximum of 256 points. Our data will potentially contain polygons with millions of points as we are mapping continents, countries, states/provinces, etc. We need to be able to use ST_WITHIN against all of these polygons. The article also mentions that we can adjust that limitation by contacting Azure Support.
Why is this limitation in the first place? If Support does remove the limitation, are we going to bring DocumentDB down with so many points?
If you want to do it all in DocumentDB (as opposed to adding something like SQL Azure), you can use an approach of narrowing down the list by using ST_DISTANCE to get candidates and then running the equivalent to ST_WITHIN client side (ray casting algorithm is simple and fast). The trick involves storing denormalized meta-data about each polygon, namely a center point (accuracy of center point not critical) and the maximum radius using that center point. Then if the distance between your point and the center minus the maximum radius is less than zero, it's in the candidate list. It works like a charm and is performant with some careful index design.
One thing to worry about is the condition where the polygon intersects itself. Do you treat the intersecting space as outside the polygon or within it? We had a nasty bug that took forever to figure out and it boiled down to a self-intersecting polygon. This problem exists whether you implement your own algorithm or use the database's native "within" function.
The short answer to your question is yes, they are worried you will bring DocumentDB down with more than 256 points. It used to be limited to just 16 points, but they changed it to 256 recently. Perhaps they will raise it again in the future. We ran into a similar problem with polygons having more than 1,000 points. In the end, we decided to use Sql Server for our polygon searches and then use the data refined from Sql Server to pull the related data from DocumentDB.
The problem is that DocumentDB resources are shared between customers so all of the operations that you run against DocumentDB have to be governed by request units. That way, no one customer can bring the system down with massive queries. I don't know how to calculate the request units from using ST_WITHIN on millions of points, but my guess is that even on the S3 tier, it would probably push the limit of the allowable 2500 Request Units. So even if they lifted the 256 points to a one million points, your query might not be able to finish because it would be too expensive. So I suggest you go with Sql Azure. That is what we settled on and it performs great.
I'm new to SQL and learning about Adjacency Lists, Nested Sets, Closure Tables, but from what I understood, these solutions usually apply to acyclic data.
I'm aware that this sort of problem may be better suited to a graphical database engine such as Neo4j, and I am exploring that also. But for this question, I specifically want to know if I can achieve this goal in SQLite.
Before running off with a possible answer for this, please help me understand how to better define or illustrate the problem. Once the problem definition is refined, then point me in the right direction (technique, reference material) and let me try to figure it out.
Objectives:
Maintain a list of areas and how they are connected.
Areas can have different types: Country, Highway, State, City, Neighborhood.
Areas can be connected in cycles (undirected).
Areas can have multiple exits.
Maintain a weighted list from one exit to another, within the area.
Extract optimal path from one area to another (from this neighborhood to nearest highway).
Assumptions:
Will use SQLite 3 (newest version).
Small data set ( < 1,000 areas and connections, < 5s DB creation).
Relatively static ( < 5 inserts or updates/year ).
May be simpler to recreate database from scratch than update?
Highways are areas, not connectors.
Streets are logical connectors, no length, no weight.
Areas and connections are like a house with many rooms with multiple doors. The doors connect the rooms. There is no traversal weight going through a door. The weight in selecting a door comes from the distance between the doors. A hallway is like an extended door, so it has a weight and is considered a type room. A room may have a large size, but if the only two doors are near each other, it may have a small weight. it's not the size of the room that counts for my purposes, but the distance between the doors.
As always, thank you for taking the time to read, and for constructive comments.
Yes, it is possible to use SQLite to store this kind of data.
It is not practical, and you may have performance issues. If you plan to store huge amount of such data and want a well scalable solution, you should go for some graph DB.
If you are gong to store ~1000 nodes, that can work with simple realtions in SQLite.
Especially since you are going to have very little number of updates, you could pre-calculate the distances. So you don't have to actually recalculate it each time, but just load from the DB.
I think you should represent your problem as a graph.
Nodes could be the "doors" and edges the distances between them.
You could store this easily in relational database. (Areas(Id,Name), Doors(Id,Area1,Area2) DoorDoorDistance(Door1, Door2, Distance))
If you have stored these data, you can calculate shortest path from every door to every other. You could store this in a new table. (Distances(Door1,Door2,Path, Distance))
To calculate shortest path you can find different algorithms:
Shortest path algorithms
After this you have the shortest path between each pair of doors.
The only question from now is witch door to take from your starting area to which door in your destination area.
If you don't want to be this precise you just take the one with the shortest path. Otherwise you have to maintain door distances from area starting points.
A; You can can assume that you start from the center of the area, so you can store door distances from the center
B; You can be more precise, by storing exact door locations and calculating door distances from an exact starting point.
In both cases you should select door with the lowest cost, both in the starting area and the destination area:
Total cost: (Walk to door distance) + (starting Door to destination Door Path) + (Walk to destination in the destination area)
I would do this like this. I hope I helped, have fun!
I am really confuse over the draw overlay
on MRI Image means its part is similar to Structure Report(SR) Processing or not
I am trying to read the MRI File in such way that from Contrast Agent. Also after so much searching on Google finally get some information such as
"The data is extracted by injecting a contrast agent into a patient’s vein,then taking sequential snapshots of a volume of interest as the contrast agent diffuses through that area"
but i am totally new for this to help out can you help me for
1. Give me specific link for these topic
2. How to read the Contrast Agent value from MRI Dicom File.
3. Also how to show a shaded region where the Cancer is detected or
some kind of marker on that location where the pixel intensity of
dicom file is higher.
Well, MRI scan is just a stack of grayscale images, pretty much as CT is, except that intensity units are of course different. So, just read it as any other dicom image, and look pixels values for intensities, or perform segmentation.
Cancer tumor regions and other features are stored in a separate dicom object, called RT structure set (it is produced usually by radiotherapy planning system or some contouring software).