Talk:Map data Structure Modelling

Note. A lot of this has already been covered over at Labels. Please also be aware of the Map Features page and the links from it to varous keys as these are being used as a basis for Osmarender.

Should specific attribute and format suggestions and recomendations be incorpoarated on individual key pages (linked from Map Features? Blackadder 07:20, 13 Apr 2006 (UTC)

Thanks for the link. There is some overlapping. I think we should consider merging at some point of time. I see this page rather as on requirement level reviewable and readable for everyone, not as an implementation level talking about a specific schema implementation.

Here will no programming terms like '=class' (as in Labels) be found and it is irrelevant, wheter the data should become encoded in XML, ASN.1 or whatever.

Though when these requirements have been carefully reviewed derivation of data schemes (like XML-DTD, XML-Schema, Relax NG-schema, Database-Schemes, ASN.1-schema or whatever) should become simple, it is a intended second step.

Labels has shown that besides the data structure, definitions have to become settled about how to describe non-obvious characteristcs e.g. the width of a lane width, the types of crossings, etc.

Here ist would be good to have a definition area that defines how such charactersitics should be measured. Having pictures would help here

Pictures

I started to upload some pictures at Tagging samples, hope the image upload works again

--

Cool! Just one picture, but a good start. Having some pictures from bridges of any type would be great too.

Josy

--

image upload didn't work yesterday evening with a server error. i took a few last saturday (to illustrate overlapping streets and tram lines, but also a few to illustrate street types) Frank 23:05, 20 Feb 2006 (UTC)

Maximum Speed

the proposed range ignores the fact that there are some unlimited autobahn segment left in germany (generally, there is no limit, but a lot of segments have speed limit signs)

my proposal: (from the labels page, with adaption to the 1 byte range)

0 : unknown

1 : at walking speed

[2,254] : given number

255 : unlimited

while i agree that 254 isn't a realistic number. (i've never seen speed limit signs with 200 or above on a street, only on stickers on the speedo that show the maximum speed for winter tyres)

You've obviously not included speed limits on high speed railways. Welshie 13:22, 21 Feb 2006 (UTC)

--

Agree that it's worth to have as alternative to an assigned speed limit something like:

• "unassigned" -> nobody has assigned a speed limit so far
• "unknown" -> speed limit is intentionally assigned to unkown
  • or
• "unlimited" -> speed limit is assigned to 'no speed limit'

instead of an assigend speed limit.

I do not like the idea of putting numbers like above suggested here. This is about encoding, I rather model here the data structure. I see no reason to limit the speed to byte size.

Josy 22:45, 20 Feb 2006 (UTC)

There is also the requirement to specify the units that the speed limit is defined in. mph (statute miles per hour), or km/h. I'd expect to default to km/h since the majority of the world is in km/h, and we certainly won't want to store "30mph" as 48.28032, or even just 48. Think about it's use, which may well be in-vehicle displays and on-screen reminders of speed limit. You wouldn't want it displaying "speed limit 29mph" when it's actually 30mph, and rounding errors have altered the meaning of it. (Legally, it's just the UK and USA that still use miles per hour for speed limits now). Welshie 13:22, 21 Feb 2006 (UTC)

Currently e.g. "Maximum speed" has 2 different types: "km/h" and "mph". Both may have a range between 1 and 250. Thus if "Maximum speed" is of type "km/h" and "km/h" has the value "20" it means 20 km/h and if "Maximum speed" is of type "mph" and "mph" has the value "20" it means 20 mph is the allowed maximum speed.

"Maximum Speed"

• shall be either of the type:
  
  1. "km/h"
     
     • or
       
  2. "mph"
     

"km/h"

1. shall be an "Integer" number within the range 1 and 250 defining the maximum speed in kilometer per hour
   

"mph"

1. shall be an "Integer" number within the range 1 and 250 defining the maximum speed in statute miles per hour
   

Thus in US or UK the type "mph" would be used and e.g. in the rest of Europe "km/h" would be used.

>> I'd expect to default to km/h since the majority of the world is in km/h

Not sure that there should be a default type. I repect countries who have choosen for strange measuring systems. :-) A default type might be considerd as something used in encoding to reduce the data volume to become transmitted. But, this is a differnt story.

It would be worth to consider, whether the units for speed and wigth would be sufficent to have at the root of the map, as it is currently with the type "Driving side". Nevertheless having those things at the root of the map makes correct display of the speed units of cross country maps like France-UK impossible.

>>even just 48. It might be worth to consider change the speed dfinition to

"10km/h"

1. shall be an "Integer" number within the range 1 and 1000 in 10 kilometer per hour steps
   

"10mph"

1. shall be an "Integer" number within the range 1 and 1000 in 10 statute miles per hour steps
   

Having the speed defined as above, would prevent encoding speed limits of 48mph or 65km/h. Are there any speed limits within 5 mph or 5 km/h steps such as 75km/h?

Josy 21:18, 23 Feb 2006 (UTC)

5 mph steps would be required for the US as they have roads with speed limits such as 45, 55, 65, 75 mph. --Colin Angus Mackay 13:30, 26 Feb 2006 (UTC)

looking for a different road sign, i came across the official list for road signs in germany, for speed limits (sign #274), they list 5 km/h and all in [10,130] km/h in steps of 10 -- Frank 11:51, 5 Mar 2006 (UTC)

On the subject of which units to use. I would go with kmh on everything regardless of what is displayed in the street. Certainly in Scotland the government's internal database systems use Kmh, even if the street signs don't. This makes calculations based on the data so much easier. If you are using the data for speaking driving directions then the rounding to whole 5mph steps wouldn't really be a problem if the data is held in integer kmh. Changing units like this is, to my way of thinking at least, a function of the user interface rather than the back end data store. For example, databases typically store the date/time in a format that is convenient for them to perform calculations on rather than what is convenient for the user. The user interface of the application will change the way the date/time is displayed depending on the locale. e.g. Todays date in UK format is 26/02/2006, in US format it is 02/26/2006, but luckily we also have ISO which is 2006-02-26 which makes it easy to write locale independent SQL - what a mess it would be if I wrote some SQL here in the UK, and gave it to an American collegue and it fell appart becuase I refered to 01/05/2006 (1st of May) and his SQL parser interpreted it as 5th of January. --Colin Angus Mackay 13:38, 26 Feb 2006 (UTC)

OK. For distances it might be better to use always the metric unit types.

Here are some miles\km values which end on '0' or '5' and have a km\mile value that comes also close to '0' or '5':

25 miles/h = 40.2336 km/h

50 miles/h = 80.4672 km/h

100 miles/h = 160.9344 km/h

40 km/h = 24.854847689493358 miles/h

80 km/h = 49.709695378986716 miles/h

160 km/h = 99.41939075797343 miles/h

My conclusion is that at least one number after the dot is needed in order to distingish between metric and a non metric value. Besides I am aware that many portable devices have no floating point CPU. This makes floating point operations very time-consuming.

Especally for street signs on km/h or weigth that I think it is better to store original value of the street sign in the database. They are not used for further calculations anyway. Or has anyone been intrested to calculate the cross border average of the maximum speed shown of speed signs for a journey?

I think it is better to store in database the unit and the interger value devided by 5 instead of using float values.

- 1 and unit 'mph' for 1*5mph instead of "8.04672" km/h

- 2 and unit 'mph' for 2*5mph instead of "16.09344" km/h

- 5 and unit 'mph' for 5*5mph instead of "40.2336" km/h

- etc.

Josy 22:59, 12 Mar 2006 (UTC)

If there is a problem with storing speeds as floating point units then just round them to the nearest integer. If you are storing a text string describing the contents of a street sign then fair enough use mph and kph, but don't mix them in a numeric database column - it violates data integrity, it doesn't even bring you to the first normal form because you are storing two different things in one column. (A speed in MPH or KPH)

For the master database I don't think worrying about what some device can or cannot handle is important. What is important is getting the information correct. If you need the data put in some handheld device then the server process that transfers the data can sort that out.

--Colin Angus Mackay 12:49, 13 Mar 2006 (UTC)

Please note that this data structure modelling is not excluively considered as basis for developing a database schemes. I consider it also as basis to derive transfer schemes, which are used for encoding data between the server and a client.

Surely it is the task of the user interface, to do coverstion of the data received in order to repesent it appropriately to the user (13:00 vs. 1:00 PM or 1.6. 2006 vs. 12/1/06 vs. 12th June 2005), however rounding of data and matching it to the closest value n or k with n*10 km/h or k*10 mph not a appropirate task of a user interfaces.

Rather the scheme should provide the capability to store in conjunction with the speed capability additional information, on whether data is strored in km/p or mph. Please explain, why it is problem for a database to handle this.

Josy 14:34, 9 Apr 2006 (UTC)

"rounding of data and matching it to the closest value n or k with n*10 km/h or k*10 mph not a appropriate task of a user interfaces" - If that is how the informatation is to be presented then, yes, it is an appropriate task of the Interface (and to clarify, I mean any type of interface, not just the interface to the user). The data stored in the database must be uniform if it is to be easily used. There isn't a problem for the data to store this, but it violates the first normal form if you store two types of data in one field/column. If you want to stored speeds in MPH and/or KPH then go a head. Just don't store them in the same place. In that case have "Speed Limit MPH" and a "Speed Limit KPH" fields.

My concern is that if the data stored with the map data is inconsistent, poorly defined and violates the most basic prinicples of data structures then the data will be next to useless and all our efforts will have been in vain. I am not spending my time on this project to have the results discarded because associated data is no use to anyone due to a plethora of inconsistencies. And putting MPH and KPH in the same field/column is inconsistent.

--Colin Angus Mackay 22:26, 9 Apr 2006 (UTC)

> I am not spending my time on this project to have the results discarded because associated data is no use to anyone due to a plethora of inconsistencies. That's exactly the reason, why I have started this page.

"Speed Limit MPH" and a "Speed Limit KPH". That is a good way to deal with it. Another way would be to store "Speed Limit". Below "Speed Limit" store either "MPH" or "KPH" and below the type "MPH" / "KPH" store the data value. This would be the way ASN.1 would deal with it. I am not sure that is a good idea for database schemes, as I am not sure, wehther with database schemes it could become restricted to put only "MPH" or alternatively "KPH", but not both or none. What would be the prefered approach for Database schemes?

By the way I gave it a first try to classify streets based on the nice pictures we have now. I have started with the motorway pictures: http://wiki.openstreetmap.org/index.php/Labels-Examples-OutOfTown#Motorway

Josy 22:12, 12 Apr 2006 (UTC)

I've updated the way the Maximum Speed is defined. Is that better now? Additional I have defined the speed types "Walkig speed", "Unlimted Speed".

Alternatively speed value could become assigend as following:
"Speed Value"

1. may be assigned to an "Integer" number within the range 1 and 500 defining the speed per hour (C.4)
   
2. may be assigned to "Walking Speed" (C.4)
   
3. may be assigned to "Unlimited Speed" (C.4)
   

(C.4): "Speed Value" shall be assigned to exactly one of the above options.

"Speed Unit"

• shall be either of the type:
  
  1. "km/h" for speed measured in kilometers per hour
     
     • or
       
  2. "mph" for speed measured in statute miles per hour
     

The option above gives "Unilimted Speed" or "Walking speed" a "Speed Unit" (either mph or km/h) which is very much irrelvant.

Which definition is preferred?

Additionally I have:

• Split Streets into ordered lists consisting of Streetsegments and crossings.
• Added Rivers
• Added Railtracks

Josy 16:23, 1 May 2006 (UTC)

National limit

Regarding the "max speed" debate, are we putting in (e.g.) 70mph for UK motorways, rather than the actual definition of "default motorway speed limit" (which is different depending on what type of vehicle you're driving) Ojw 11:51, 2 May 2006 (UTC)

Good point! Unlike in many other contries like UK, in germany there is no default speed limit - it is just unlimited. Havining a "default speed limit" would very well fit into the concept. However there are some issues that need to be clarified.

1. "default motorway speed limit", "default country road speed limit" vs. just "default speed limit"
   
   • As any street should have a street type. There is little benefit of additionally defining that a street is of the type "motorway". It is just double information, that could become inconsistent.
     
   • As the "default speed limit" for each street type is country dependent, in order to calculte the applicable speed limite, the schema must provide a way to determibe the coutries where the road is located. Maninly I see the following 2 options:
     
   1. The schema must provide the borders of the countries in order to be able to determine by calculation the country the road belongs to.
      
   2. The schema must provide beside the information, that the speed is limited to "default speed limit" additionally identify the country.
      

Besides this, the schema must provide for each country a list of the applicable street types and their default speed limit. I becomes even worse, if the appliable speed limits vary by vehicle characteristics such as car type (car, truck, ...), by vehicle size or vehicle weight.
Wich vehicle characteristics are appliable for which countries? In Germany it's Vehicle Weight as far as I know.

"Maximum Speed"

1. may be assigned to "Speed Value in km/h" for speed measured in kilometers per hour (c.4)
   
2. may be assigned to "Speed Value in mph" for speed measured in statute miles per hour (C.4)
   
3. may be assigned to "Walking Speed" (C.4)
   
4. may be assigned to "Street Type Default Speed Limit" (C.4)
   

(C.4): Maximum speed shall be assigned exactly to one of above types marked with C.4.

"Speed Value in km/h"

• shall be an "Integer" number within the range 1 and 500 defining the speed in 5 km per hour steps

"Speed Value in mph"

• shall be an "Integer" number within the range 1 and 500 defining the speed in 5 mph steps

"Walking Speed"

• shall be empty and contain no further data
  

Option 1:

"Street Type Default Speed Limit"

• shall be empty and contain no further data
  

"Street Type Default Speed Limit"

• shall contain the contry identifier
  

Josy 21:41, 4 May 2006 (UTC)

Created a new ASN.1 Schema describing above: ASN.1 Schema

Josy 15:57, 24 September 2006 (BST)

Single lane bridge

Do driving side, forward direction and reverse direction handle one-lane bridges gracefully? Such a bridge is used in both directions, but not simultaneously. Rw 04:44, 8 October 2006 (BST)