osm.org/#map=19/50.63606/5.56980

ein vorbild wie detailliert es sein kann.

It depends a bit on what you need the icon for. Geometric might be fine if you do not want to show a lake at all but just represent it somewhere for mathematical purposes.

But if the goal is to show an icon on top of the polygon the first method can be extended. Use it to determine the position A. If A is not in the polygon, or too close to the polygon edge, divide the bounding block in 4, and find out which of the 4 has the most polygon arean in it. The midpoint of the winner is point B. As the icon position, then try the point between A and B.

For multipolygons it may also be worthwhile to determine the largest first and only process that. But for an archipelago it is probably best to start with geometric middle. Maybe a rule that uses the middle of a ‘main’ subpolygon if it exists (for example, use the largest polygon if it is larger than (total area)/sqrt(number of subpolygons).

The search for a perfect solution will be determined by the exact question asked, as a multipolygon will never be perfectly reflected in a single pin.

Yup, I see the tiles re-rendering already. Thanks!

Why the negative view? It is probably better to learn from others and improve OSM even further.

The travel times are already available at Google and Waze (heck, even offline TomTom units report travel speeds back to the mothership when they are updated).

For OSM something similar could be achieved. Give the users of maps (OsmAnd, …) the possibility to report back travelled routes and their speed, and that data can flow into OSM. Make it part of an “OSM application kit”. And make it smart, it can upload off line, when the user installs map updates. Make it trivial for the user and easy for the developer and the data will flow.

The easiest one would be to report on which spots routes are recalculated, i.e. where the user makes a mistake or does not agree with the decisions. The second is to collect segment speeds.

I think node IDs may get lost when data is preprocessed for navigation, but it might be the way to go anyway: the apps report travel time between nodes associated with a turn, and if the node ID is not available because it got lost in translation or the user is ‘off the map’ report the coordinates. And report some more if great distance and time have elapsed singe the last turn. That should be a nice small bit of code. Add some metadata to each report (App name, OSM map version date).

Privacy can be an issue: for this purpose date and time are needed, which are at least in some stages tied to the device. Anonymizing on upload makes sense.

SPAM

SPAM

Really really straight roads should not have too many points, I’d think. Curves need them, even if unsure on how they run.

Thus, trustworthiness is better gained from other aspects, right?

But I agree that when building a road from a noisy track it is better to err on the ‘straight’ side. Otherwise precision would be suggested that doesn’t exist.

SPAM

No map is perfect. And people break things. But if the “Neulinge” do good work after a while that will probably be more helpful than the defects they caused in the beginning.

My suggestion would be to fix certain features because they are ‘known to be perfect’. The person declaring them perfect can then review changes - maybe instead of editing the feature, the user can send in a bug report that will go to the person declaring the feature ‘perfect’.

@ubanverleih,

The GPS is most phones is fine I think. The idea is that a human interprets the photo anyway. The output will be geotagged photos of traffic signs, just like we have GPS traces now.

The biggest source of error will be time. GPS position is often a second behind reality. Also the processing delay needs to be taken into account.

I would suggest using a smartphone as camera/processor. Better to have many people driving each not so much, compared to a few people with special hardware,

osmAnd is also a very useful app that shows openstreetmap maps (from the internet or downloaded to the phone) and shos your track on it, or tracks from the past. The menu structure is a bit confusing though:

• there is a main screen with map / search / favorites / settings
• on the map screen, there is a tiny gear to slect what you see on the screen (next turn. which way is north, the button to turn tracking on, etc)
• on the map screen, the menu button can be used to determine which POI to show on the map, and which GPX trace (also the current trace, but it shows only one at a time.

It does a lot more than viewing the map and track and position, for example reasonable navigation, POI editing, annotation.

When I’m in another country I really like that I can download maps before I leave.

Hmmm… as highway=track it renders dotted. Changed it anyway. Maybe someone can chime in whether this road is actually useful for non-local car traffic (I doubt it).

I also note that the road is tagged psv=yes. That seems to mean ‘to ordinary traffic can pass here’ - which does not seem true.

Well, with flood it has a few meters of water, so the only vehicle applicable will be a boat ;)

I’m going for ford=yes, access=tidal, and downgrade it to highway=unclassified. The downgrade because it is not really for normal traffic; there is a much better bridge nearby that is not slippery and a lot wider.

Causeway does not seem to be the right tag; that seems to be a road on a kind of dyke or a road on poles like a low bridge that is too low to pass under, like the road connecting Venice to the mainland.

Indeed, nice method to map POIs without using GPS.

SPAM

SPAM

SPAM

SPAM!

SPAM!