I'd like to use a URI scheme to enable the users of one of my apps to share geographic locations.
I don't want to invent my own URI scheme and "geo" seems the most appropriate but there are only two Internet Drafts on the subject (draft-mayrhofer-geo-uri-01, draft-mayrhofer-geo-uri-02), both expired and wildly different in the way they approach the standard.
Is there an URI that's suited for encoding latitude and longitude and that made it as an RFC? Should I use a generic URI such as the tag URI scheme?
final note: The draft is now in the RFC Editors queue within the IETF, so it should become an RFC within the next 3 - 5 months.
https://datatracker.ietf.org/doc/html/draft-ietf-geopriv-geo-uri-07
the latest draft is from February 12, 2009. looks like the way to go.
The geo URI scheme definition is now RFC 5870 (since June 2010):
http://www.rfc-editor.org/info/rfc5870
Related
I'm using the Here API to calculate routes for trucks with 40t. Using the HERE devtools, i got the same error of my APP. The answer is "The API can't calculate the route because of illegal access". I checked the map (image attached) and in the street where my journey will start, with a difference of some meters, it exists two limitations 12t and 18t. The street is one way... If you see the satellite image exists several trucks... The company is testing the software says the trucks goes their...
Can some help me on this?
https://fleet.api.here.com/2/calculateroute.json?waypoint0=41.325299,2.141551&waypoint1=stopOver,3600!41.3291843,2.0317197&waypoint2=stopOver,3600!40.91260530,-8.42291420&waypoint3=38.855951,-9.104382&mode=fastest;truck;traffic:enabled&departure=2020-08-19T02:57:58&alternatives=0&weightPerAxle=14t&limitedWeight=40t&height=4m&width=2.55m&length=16.5m&trailersCount=
If you want to ignore the restrictions for trucks in the route, add the parameter truckRestrictionPenalty and set the value to soft.
The route violating truck restrictions is indicated in the response with dedicated route and manoeuvre notes. The route with the note of the type violation and the text truckRestriction may be travelled at your own responsibility. While driving on such a route, extra care has to be taken as it may result in a vehicle or road infrastructure damage.
You can read more about the parameter here.
Thanks for your feedback, but we are using the Fleet Telematics Api not the Routing API. Using your info, We researched a litle more and we found the equivalent parameter: ignoreWaypointVehicleRestriction.
We added these params &ignoreWaypointVehicleRestriction=5000;0;all and the API returned the route with the warning.
Thanks,
I have searched the questions here and gone through a fair amount of the API. I have not found reference to requesting historic route data. My questions is this; Does the Here api support historical route data. An example request would be that I seek the mileage from point a to point b 365 days ago, when perhaps a key route obstruction existed such as a bridge was out or a road was closed for construction that resulted in more miles during that historic period.
I would like to answer this in two parts
Can a route be calculated for a past date ?
Yes, you can. You need to request a Time Aware Route like below. You can read more about it in the developer site.
`
GET https://route.api.here.com/routing/7.2/calculateroute.json
?app_id={YOUR_APP_ID}
&app_code={YOUR_APP_CODE}
&mode=fastest;car;
&waypoint0=geo!37.743385,-122.422835
&waypoint1=geo!37.743878,-122.423686
&departure=2014-03-12T10:00:00
&routeattributes=sh,bb,g
`
Will the map used for the query depend on the departure date ?
No, Here API always uses the current version of the map available unless you specify explicitly the map version. But you can specify only till previous two releases.
So for your question, you wont be able to get the map data for a past year even using map version. But what you can do, is explicitly avoid the bridge or road newly constructed so that the api doesn't suggest that route. You can do this through Custom Route Extension API like below example.
GET http://cre.api.here.com/2/overlays/upload.json
?map_name=OVERLAYBLOCKROAD
&overlay_spec=[{"op":"override","shape":[[50.10765,8.68774],[50.10914,8.68771]],"layer":"LINK_ATTRIBUTE_FCN","data":{"VEHICLE_TYPES":"0"}}]
&storage=readonly
&app_id={YOUR_APP_ID}
&app_code={YOUR_APP_CODE}
I have read about the differences of the URI, URN and URL here and here but the answers talk of the differences of the last letter, that is, the differences amongst identifier, name and location respectively.
What I have not understood is why all these terms have the word 'uniform' and what is uniform about them. This Wikipedia section doesn't mention much about the reason why the change was made from 'universal' to 'uniform'.
I would like to find the missing explanation and not just memorize the terms as they are without fully understanding them.
Based on Tim Berners-Lee’s own account, as published in his book Weaving the Web:
At an IETF meeting, Tim Berners-Lee tried to form a working group that would create an Internet standard for what he suggested to be named universal document identifiers.
About the meeting, in his words (page 61):
[…] there was a strong reaction against the "arrogance" of calling something a universal document identifier. How could I be so presumptuous as to define my creation as "universal"? If I wanted the UDI addresses to be standardized, then the name "uniform document identifiers" would certainly suffice.
While he didn’t agree (it was an issue of whether the Web could be something "universal"), there wasn’t much time and so (page 62):
I was willing to compromise so I could get to the technical details. So universal became uniform, and document became resource.
They formed "a uniform resource identifier working group". (And this group then decided that "identifier" wasn’t a good label, and they chose "locator" instead, forming "URL" – which he also didn’t agree with.)
The current URI Internet standard (RFC 3986) describes the meaning of "Uniform", "Resource" and "Identifier" in section 1.1.
Assume an absolute http or https URL. I'm looking for an "official" or generally accepted name for the part of the URL that comes before the path.
http://foo:bar#example.com:8042/over/there?name=ferret#nose
\_____________________________/
|
this part
RFC 3986 defines the URL syntax parts as follows:
http://foo:bar#example.com:8042/over/there?name=ferret#nose
\__/ \______________________/\_________/ \_________/ \__/
| | | | |
scheme authority path query fragment
RFC 6454 defines the origin (as in "same origin") of an the URL as the triple (scheme, host, port):
http://foo:bar#example.com:8042/over/there?name=ferret#nose
\__/ \______________/
\________________/
|
origin
As such, neither term is appropriate. Is there a good term for the part I'm looking at, or am I stuck with "scheme (plus ://) plus authority"?
The name in practice and per the current URL standard for the part of a URL that comes before the path is in fact just origin.
The :// part of a URL is just a syntactic (or lexical?) artifact that there’s never any real need to mention in discussions about actual behavior of anything that consumes or processes URLs (other than low-level parsers of course).
The username-password part is a non-conforming misfeature that’s now only useful to discuss as a historical error. The relevant part of the current URL standard has this to say about it;
There is no conforming way to express a username or password of a URL
record within a URL string.
So again in practice for any normal discussions of URLs that align with how the current standards define URLs, it’s sufficient to speak about a URL simply in terms of its highest-level parts being just four parts: its origin, its path, its query (part), and its fragment (part).
Certainly that is at least what the current URL standard itself limits it to.
It would have to just be "scheme plus authority". Bear in mind, that you can't have a valid URI that just has a scheme plus authority, so the combination doesn't come up much as a unit to discuss, and so didn't end up with a name.
Note also that userinfo has never been allowed in HTTP URIs; particular schemes can prohibit or restrict the values of particular portions. Some browsers had a design flaw where they would accept userinfo and base authentication headers on it, but most now will at least warn about this being done, if they allow it at all.
Is there an ISO standard address format? I can't seem to find one, and I'd like to know for object- and database-design purposes.
(One interesting document that shows a bunch of formats is this: http://www.bitboost.com/ref/international-address-formats.html, but it's insane!)
No; each country defines its own standard.
There have been a number of questions about this in times past, including:
Best practices for storing postal addresses in an RDBMS
Is there a common street address database design for all addresses of the world
The second of those itself has references to a number of other SO questions.
You might want to check out the grandiosely named Universal Postal Union and its standards.
There are none. However, you can also consider that place is usually contained in a bigger place.
So, you can also use the hierarchical structure of places in following an address format. Which also means it differs from country-to-country.
You can read stuffs about this on:
Universal Postal Union's paper Addressing the world, an address for everyone
Place ontology from schema.org
PostalAddress ontology from schema.org.
Check out the address below.
Address standards
A collection of information on address standards
ISO 19160, Addressing
https://standards.iso.org/iso/19160/
http://www.isotc211.org/