jutezak has commented on the following diary entries
|To all recklessly editing newbies||9 days ago||
Making tags is hard. Especially with the international differences in cafe's, restaurants, lunchrooms, bars, pubs. Or pharmacies and drugstores.
And double functions: supermarket AND pharmacy. Or pub AND restaurant.
|The wrong side of mapping transient events in OSM||5 months ago||
Also keep in mind that OSM data gets copied and teh copies used, for example for navigation.
It could make sense to mark transient changes as such. For the speed limit, that is straightforward and an exporter could disregard the temporary tags, instead using unlerlying permanent tags.
For road changes (for example, near Eindhoven (NL) a reconstruction of an important roundabout caused a closure of multiple months) the roads should be tagged as 'no access temporarily' and re-arranged and the tags removed. FWIW Google maps showed the roundabout as really 'gone' during the works - but no one is supposed to export their map data.
Thus I think it could work in a clean way.
For the longer term I feel multiple OSM 'layers' are the solution: a base map with things that do not change much, like actual roads, road names, and buildings, rivers etc. A separate layer then contains attributes such as maxspeed, one way tags, etc. And another layer could contain detailed data about businesses (the name of the restaurant ion a specific building, for example). The UI doesn't need to change, but there could be lower barriers to entry for changing attributes on a road or business. Exports of the changes can be a lot quicker. And the risk of someone deleting the whole road when it is just closed for repaving is reduced.
|Zuviel des Guten||5 months ago||
I feel a solution may be in a different data model. Do not import (copy) data into OSM, but link it. That will stop problems such as the imported data going stale.
This would would for things like opening hours and restaurant menus.
As for the routing, that could be an export thing. If the map contains seperately drawn sidewalks, relations with the road, and the road is tagged as 'easy to cross' (is there a way to tag that? I've seen road type examples, but never if that type is easy to cross on foot, but I may have missed it). This also matches some example that I have seen on a more detailed GIS, which maps road widths etcetera - and which is also exported down to the little detail available in a car nav. So there could be an export available that collapses these road into the more simple multifunctional one.
Maybe these 'pains' the result of getting too big (both in detail and in scope) for the current data model. For the POI detail database (restaurant menus, opening hours) that might be not too hard to split off. It would reduce effort for the map editor maintainers, and allow a much better UI for the updaters. The risk of editing POI contents is lower, so the barrier to entry should be as well.
|Hotel Il Monte||6 months ago||
|Cho thue may photocopy giá rẻ||7 months ago||
|Agen Bola Terbaik - Agen Casino Resmi - Agen Judi Online Terpercaya - Lucky9casino||7 months ago||
|Poor man's rendering||7 months ago||
What would be nice: if POI were rendered asseparate bitmaps on top of the tiles.
A single tile layer could then support different uses depending on the added POI. Something like it seems to be in use for highlighting ways.
In any case, for teh original author: try a vector rendering program that uses OSM and enable ALL the POI. You won't see a map any more because of the trees, recycling stations, fire hydrants, phone booths, shops, tagged buildings, traffic lights, boulders, speed bumps and so on. Then you are luck so little art works have been mapped so far :)
|Artwork : only for tourists||9 months ago||
Ah well, tags...
Even restaurants confuse me. A lunchroom can be high quality food which would place it out of the fast food taging. but a restaurant it is not. And how about cafe (with just coffee and pie) and cafe (coffee and beer) and bar and pub?
Why not tourism=restaurant anyway? Sensible people should eat at home if that is nearby ;)
|Häuser mit Nummern||11 months ago||
ein vorbild wie detailliert es sein kann.
|Mittelpunkte von Flächen und Multipolygonen||12 months ago||
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.
|Stretched portion on map in Spain||about 1 year ago||
Yup, I see the tiles re-rendering already. Thanks!
|waze + google = good news for OSM||about 1 year ago||
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.
|dexoping||over 1 year ago||
|Enfamil coupons||over 1 year ago||
|Node density||over 1 year ago||
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.
|Italian jewellery||over 1 year ago||
|Es könnte alles so perfekt sein...||over 1 year ago||
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'.
|Datensammelmaschiene selber bauen||over 1 year ago||
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.
|Datensammelmaschiene selber bauen||over 1 year ago||
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,
|Found an android app for OSM Tracker, upload my first GPS tracks, and start translating the app into Traditional Chinese.||over 1 year ago||
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:
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.