jutezak has commented on the following diary entries
|COFFEEDEX & the single-tag revolution||20 days ago||
Hmm even though I like the idea of adding data, this data is not really geographical.
It is also subject to change. The price would also need an asociated date.
Actually this kind of data would be very useful in separate-but-linked-to OSM data.
Think traffic information: that data is too fast changing to put on the map, but when you plan a route, you need to know which parts of which ways are free to move on. Finding these from OSM to whateverservice is similar to finding a coffee shop in OSM and looking up the price in service B.
If you see the 'coffee price' as an indicator of 'general price level', things change a bit. But even this is not really geo data.
|Wie geht es jetzt weiter?||3 months ago||
One should either:
Upload the trace to Openstreetmap.org. Do this in the app. You can find them in ine on line Potlatch 2 editor, so you must set that as default. Go to Settings on Openstreetmap, and around the middle of the screen slect Potlatch 2 as the default editing program. Then, on the Openstreetmap site, you can find them back using the instructions from hecktor on 14 september 2014 at 09:37.
Or one could (no Flash plugin needed):
Use OpenStreetMap to view the area you want to edit. At the top left, click 'Edit'. make sure the iD track editor is used (it is the default, you can also select it with the little arrow next to the edit button). You will see the editable map on screen. To view your trace, drag the .gpx file from your computer's desktop into the editing window. It will be shown immediately.
So there are 2 ways which are rather different.
|risotto maken||3 months ago||
|We can no longer go on like this||4 months ago||
The freedom OSM allows in tagging and organizing might be the problem here. NOT the freedom to start mapping.
Slowing things down, extra popups, forcing comments: they try to make mappers more careful. But the mapper still thinks he's doing the right thing!
I think that editing at a higher level of abstraction is the solution. Not nodes, ways, tags, and relations for the average user. But a crossing. Street. Building outline. Country border. River. Each can be given an example to clarify (Highway, for example the A1 motorway).
That would make for an easier start and prevent mistakes. And get more consistency as a bonus.
|First edits to Openstreetmap||4 months ago||
It will be discovered, but will not be really busy.
And indeed, usage can be key to preservation.
|To all recklessly editing newbies||5 months 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||10 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||10 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||11 months ago||
|Cho thue may photocopy giá rẻ||11 months ago||
|Agen Bola Terbaik - Agen Casino Resmi - Agen Judi Online Terpercaya - Lucky9casino||12 months ago||
|Poor man's rendering||about 1 year 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||about 1 year 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||over 1 year ago||
ein vorbild wie detailliert es sein kann.
|Mittelpunkte von Flächen und Multipolygonen||over 1 year 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||over 1 year ago||
Yup, I see the tiles re-rendering already. Thanks!
|waze + google = good news for OSM||over 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||almost 2 years ago||
|Enfamil coupons||almost 2 years ago||
|Node density||almost 2 years 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.