Re: [Talk-us] Things that are not buildings but are used as one

[Martin Koppenhoefer]

> Am 01.06.2015 um 16:40 schrieb Jack Burke :
> 
> Is it correct to tag a non-building object with building=yes if it is 
> functionally used as one? 


although it may not be semantically correct, the building tag is indeed used 
like this. Please note that also many structures that technically aren't 
buildings are often tagged with the building tag

cheers 
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Fwd: Re: [OHM] Fwd: moving data from OSM to OHM - what should the markers be?

[Martin Koppenhoefer]

> Am 18.05.2015 um 15:11 schrieb Richard Welty :
> 
> in OSM, i tag at least the basic, visible course as highway=track,
> with start_date and end_date when known (which is usually the
> case for US and Canada tracks - i have references which


I am not familiar with the context/setting but wouldn't use highway track for a 
way that is not built for agricultural/forestral/fishing purposes, 
highway=raceway would be better (also because your start and end date tags are 
referring to this, not to the highway=track)


cheers 
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Great Lakes Boundaries

[Martin Koppenhoefer]

> Am 24.04.2015 um 17:23 schrieb AJ Ashton :
> 
> Yes, if Lake Superior is mapped as natural=coastline (which I think is the 
> easier-to-maintain approach for such a large & complex water body) then we 
> should remove natural=water from the multipolygon relation (r4039486). Does 
> anyone have any objection to this? It's causing some noticeable rendering 
> issues both in the standard style and for data consumers.


yes, if the coastline tag remains it seems logical to remove the natural=water 
tag. Semantically the coastline tag on a freshwater lake is clearly wrong, but 
it seems to be an accepted compromise in this case: 
http://wiki.openstreetmap.org/wiki/Tag:natural%3Dcoastline#What_about_lakes.3F


cheers 
Martin ___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Am I doing this right? Houses w/ addresses

[Martin Koppenhoefer]

> Am 11.04.2015 um 16:47 schrieb Steve Friedl :
> 
> but this presentation with numbers scattered all over just doesn’t look 
> right, so maybe I’m doing something wrong.
> 
>  
> 

don't worry, the current rendering of house numbers is more aiming at the 
mappers (to give an idea of completeness) rather than to look pretty for a 
general map consumer...

cheers 
Martin___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Facts about the world

[Martin Koppenhoefer]

2015-04-08 9:05 GMT+02:00 Simon Poole :

> The wiki already explains: they hold a trademark for GR which makes
> using the "official" names of the routes essentially impossible in and
> for material they hold protection for and further they seem to claim
> copyright on the routes themselves, which is not particularly far
> fetched and can't be dismissed out of hand.
>


I do agree that they might likely have copyright on the routes, and that we
maybe can't reproduce their routes in our db, but I do question that we
can't map their signposts. Reasoning: the routes are nothing physically
existing, they are, similar to a novel, creative works made up by someone,
and that someone will probably hold copyright on them. The routes are not
facts, they are works of creativity and ingenuity. But the signposts are
facts, observable in reality, and while their graphic layout, logos,
colors, composition, fonts, text, will likely be protected by copyright,
I'd question the concept that their pure existence cannot be told about
(i.e. without reproducing them with a foto, drawing or similar).

Cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Facts about the world

[Martin Koppenhoefer]

2015-04-04 16:46 GMT+02:00 Simon Poole :

> Sorry for the late answer, been on the road for two days and now are on a
> rather flaky network connection.  See
> http://wiki.openstreetmap.org/wiki/Walking_Routes#France for a very short
> synopsis of the GR issue.
>


is this something the OSMF lawyers have had a look into? Is the issue
really "copyright" or is this about "trademark" (regarding the names "GR"
"PR" etc.)? Currently it seems we are accepting what the Fédération
Francaise de la Randonnée Pédestre claims, without questioning whether
their claims hold up.

E.g. why can't you do a survey and publicly say: "here is a sign which
reads GR 4" similar to making a survey and publicly saying: "here is a sign
that reads 'Coca Cola'"? This doesn't question the CocaCola trademark.
Also, we are mapping roads and buildings, but the projects leading to these
constructions are normally protected by copyright, and also a building can
be protected (architectural work). None of these do stop us to map them in
other fields, what is the particularity why GR cannot be mapped?

Cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Retagging hamlets in the US

[Martin Koppenhoefer]

2015-03-22 4:00 GMT+01:00 Clifford Snow :

> At its most basic, OSM is a geospatial database. We have countries,
> states, counties, and cities. Why not neighborhoods. OSM tells where a
> feature is located. Points can only tell us how close a feature is to a
> node. Using nodes to represent neighborhoods doesn't allow with any
> certainty where a feature is located while a polygon can.



+1

Cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Retagging hamlets in the US

[Martin Koppenhoefer]

2015-03-18 3:48 GMT+01:00 Bryan Housel :

> (IMO the “Bender’s Corner” hamlet should probably just be deleted
> outright.  I live near it and there really is no such thing.)



or maybe keep it as a historical place name, something like place=locality
and old_name="Bender's Corner"? I agree that this is something local
mappers with local knowledge should decide upon.

Cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Weigh stations on Interstates

[Martin Koppenhoefer]

2015-03-16 17:33 GMT+01:00 Harald Kliems :

> In continuing mapping destination tag on highways based on Mapillary
> imagery, I've come across the problem of how to tag weigh stations on
> Interstate highways (http://en.wikipedia.org/wiki/Weigh_station). I
> haven't found anything in the wiki, and I don't know enough how they work
> to come up with reasonable tagging.
>


some years ago, scales have been discussed on the mailing list, but it
doesn't seem if this has lead to a lot of tagging:
http://taginfo.osm.org/tags/man_made=weighing_scale#overview
There are also 12 amenity=truck_scale

For those weighing stations I'd see them as a bigger object with the scale
just being a part of it (if I understand that correctly), could be
something like amenity or highway=weighing_station

Cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Bus "flag" stops?

[Martin Koppenhoefer]

2015-03-08 16:12 GMT+01:00 Paul Johnson :

> On Sun, Mar 8, 2015 at 5:22 AM, Martin Koppenhoefer <
> dieterdre...@gmail.com> wrote:
>
>>
> If someone pulls the cord or there's someone waiting at it, yes.  But it's
> not like a bus station where the bus will always stop regardless of demand.
>


I won't see this as a problem, indeed in rural areas around here, almost
all bus stops (with exception of the terminal stop and some important ones
in city centers) work like this.



>
>
>> Where would you wait if you wanted to take the bus at this stop?
>
>
> Next to the road roughly guesstimating the closest safe spot for the
> driver to stop at.
>


I'd put the stop in OSM at that position. Even if it is not marked in any
way (what would be easier for mapping purposes) it is still a bus stop in
the end.



>
>
>> Or is it just for getting off?
>
>
>  No, you can board, too.
>


I'd tag them as highway=bus_stop (or whatever scheme you prefer, or both),
and if you want to get detailed add stuff like bench=no, shelter=no etc.
You'd likely have to know the area well in order to locate those spots, or
are they "dynamic" (meaning you can waive your hand in any place along the
route and the bus will stop)? In this case I'd not map any bus stops (as
there aren't actually "spots").

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Bus "flag" stops?

[Martin Koppenhoefer]

> Am 07.03.2015 um 20:34 schrieb Paul Johnson :
> 
> How do we deal with bus stops that exist in transit schedules but have no 
> physical presence?


does the bus stop always at the same stop? Where would you wait if you wanted 
to take the bus at this stop? Or is it just for getting off?

Cheers 
Martin 
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Why?

[Martin Koppenhoefer]

2015-03-05 1:14 GMT+01:00 stevea :

> What I understand Martin Koppenhoefer to say are essentially the same
> things, but I'm not sure if he understands (or agrees) with Escondido
> having large areas marked as landuse=residential.  These are not simply
> zoned residential (they are), they ARE (on-the-ground verifiable)
> residential.  So it is OK for them to be tagged as they are.



Yes, I'm saying the same things. In particular, if you ask me about these
huge landuse polygons in Escondido, I don't particularily like them. I like
detailed mapping, and I believe as soon as someone starts to map the
details he'll have to split these polygons into smaller ones in order to
keep maintainability. I don't suggest to make them multipolygons and to
exclude stuff, this would become a nightmare very soon.

I would exclude (at least) the main arterial roads from the residential
landuse and also stuff like this:
http://www.openstreetmap.org/way/65592897

And when you did this, you'd already have it all split into much smaller
landuse areas.

Cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Why?

[Martin Koppenhoefer]

2015-03-03 18:55 GMT+01:00 stevea :

> What Hans calls a "mega residential area" is actually local zoning which
> says that all properties (parcels) in a given area are zoned residential.
> While not strictly true that each square meter of this area has residential
> buildings upon it where people live, it is true that each square meter of
> this area is ZONED residential.  In my opinion, this is a "loosely correct"
> way that OSM might represent a particular area,



landuse in OSM should be the actual landuse, not the legally permitted /
designed landuse (zoning).

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Place classifications

[Martin Koppenhoefer]

2015-01-09 12:45 GMT+01:00 Minh Nguyen :

> but more importantly, it accurately reflects what "going to town" means in
> the surrounding area. That seems to be the idea behind the wiki's nebulous
> definitions.



+1

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] User randomly adding speed limits across the US

[Martin Koppenhoefer]

2014-12-01 18:41 GMT+01:00 Clifford Snow :

> I wonder if adding default maxspeed to the city admin boundaries would be
> an easy way to post these city/county limits? The alternative is to add the
> maxspeed to every highway segment in a city.



we're doing the latter around here. It seems a huge redundancy
introduction, and indeed it is, but it works ;-)
Keep in mind how osm works. This way of doing it has the advantage that it
is easy to understand and maintain, because having the default added to
some boundary only would require mappers to look for this boundary
(typically you will just download a small chunk of the city and do your
edits there, you probably won't have this boundary poly in your editor).
And there might be more than one (overlapping) boundary polygons, if those
had different maxspeeds tagged it will not be much fun to find the problem.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] User randomly adding speed limits across the US

[Martin Koppenhoefer]

2014-12-01 17:05 GMT+01:00 Paul Johnson :

> We just get crazy with it.  The two signs below tend to be common in
> Oklahoma.  Entering most towns you see a sign similar to this one:
> http://imgur.com/QhYtLhl
>



so what's the limit in alleys then? ;-)

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] User randomly adding speed limits across the US

[Martin Koppenhoefer]

2014-11-30 4:09 GMT+01:00 Paul Johnson :

> We have a similar convention in the US for doing that, though usually
> requires tagging traffic_sign=maxspeed, maxspeed=?? mph in a few places,
> since there's often multiple "steps" from rural speeds to town speeds when
> entering a town or city




yes, that's what we do as well, but it is different in that these are
explicit maxspeed limits, while a "city_limit" traffic sign is an implicit
speed limit (we are using both, according to which signs there are). We'd
also add source:maxspeed=sign / IT:rural / IT:urban / IT:motorway etc. tags
on the way with the maxspeed to say where it comes from (useful in case the
default implicit limit changes).

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Updating tagging of public transport

[Martin Koppenhoefer]

2014-11-27 21:08 GMT+01:00 Saikrishna Arcot :

> Not sure if this is the right list or the tagging list is better, but I
> see some bus and subway routes in the Atlanta area that use the older
> version of tagging public transport routes. Should these be updated to use
> the newer version of tagging?
>


it is not clear if the new way is actually better, at least the current
data stats show that mappers still prefer the "old" method, at least for
bus stops, as it is simpler (you need just one tag highway=bus_stop instead
of two: public_transport=platform and bus=yes, for the same information
content), and the new style cannot be rendered on the main map, because of
the lack of the bus-key (the rendering db only "knows" that there is some
kind of stop, but it cannot determine if it is a tram stop, a bus stop or
whatelse).

I wouldn't "re-tag", ie. won't remove tags, but you can add the
public_transport=* tags if you want to support also this scheme.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Who controls data: Google Maps, others erasing Hollywood sign, but it's in OSM

[Martin Koppenhoefer]

2014-11-27 18:04 GMT+01:00 Brad Neuhauser :

> Could you include the new node in the relation as role=label? That's at
> least somewhat documented...




mapping "labels" is generally disputed, as a label is something the
dataconsumer creates to display information, it is not actual information
to describe the world, that would belong into the osm database.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Who controls data: Google Maps, others erasing Hollywood sign, but it's in OSM

[Martin Koppenhoefer]

2014-11-26 18:30 GMT+01:00 Andrew Wiseman :

> That was me -- but I would argue it's an unusual way to tag it -- it's not
> the individual letters that are important, it's the whole piece.



yes, that is clear, and the data in OSM also reflected this by having a
site relation to group all the letters into the actual monument. That
relation is the object to put the name, wikipedia link, tourism=attraction
tag etc. (and they are all there).



> You wouldn't tag each president in Mount Rushmore and leave it at that,
> right?



I wouldn't leave it as that, but I also wouldn't tag them singularly and
then add another node for the whole, I'd rather try to combine the
"individual presidents" into a whole piece of artwork by using a relation.


cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Who controls data: Google Maps, others erasing Hollywood sign, but it's in OSM

[Martin Koppenhoefer]

2014-11-25 16:48 GMT+01:00 Andrew Wiseman :

> Interesting, but now it doesn't render. I saw it was gone and worried
> somebody from that article took it off. Can we include a point in the
> relation for it, so that it does render?



Someone has indeed done this. IMHO we shouldn't duplicate the data (or
non-data, in this case there are no more tags than name and
tourism=attraction on the new node), we should find a way to render the
name from the relation without "tagging for the renderer"-hacks. This would
include changing osm2pgsql to deal with site-relations.

I couldn't find any ticket for site-relations in the osm2pgsql and
osm-carto repos, so I have added them.

cheers,
Martin

http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] admin level for US states

[Martin Koppenhoefer]

2014-11-25 10:59 GMT+01:00 Sarah Hoffmann :

> admin_levels have been invented "in order that different borders can be
> rendered consistently among countries" according to the wiki[1].
>


+1, that's also what I am after.



> That's
> also what I remember. "State eqivalent" doesn't mean that they must be
> organised exactly in the same way but that they are roughly at the same
> level of administrative hierarchies.
>


+1
my point was, that they aren't. Italian regions aren't roughly at the same
level of administrative hierarchy than are the US States, and I guess also
the French regions aren't.
Japan does have states on admin level 3.



> Under that definition US states are
> the same as German bundesländer, French regions, Canadian provinces etc.
> even though their political influence and internal organzisation is
> wildly different.
>


how could you compare hierarchical levels if the organization is wildly
different?



>
> There is a lot of software around that works under the assumption that
> US states (and the equivalents in other countries) can be found at
> admin_level=4.
>


and this would break if level 3 was used?



> The current admin level hierarchy is not perfect but
> it works for most practical applications.
>


actually it seems that changing the rendering to administrative polygons
rather than using place nodes will create/reveal some inconsistencies and I
was trying to fix this / find a solution. Maybe you are right and the
solution is not in modifying the US state admin level but changing
elsewhere. It simply seemed kind of an inconsistency to have the US state
at the same level as German Länder and French Region, but maybe that was a
misinterpretation of the admin levels.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Who controls data: Google Maps, others erasing Hollywood sign, but it's in OSM

[Martin Koppenhoefer]

2014-11-24 22:28 GMT+01:00 Andrew Wiseman :

> The trails mentioned in the article seem to be present in OSM, although
> with the gates mentioned:
>
> http://www.openstreetmap.org/node/3202722073#map=16/34.1339/-118.3214
>



I have deleted this (recent) node, because the object was already mapped in
greater detail:
http://www.openstreetmap.org/relation/1706337

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] admin level for US states

[Martin Koppenhoefer]

2014-11-24 21:18 GMT+01:00 Minh Nguyen :

> Assuming this table reflects the actual state of the map, most countries
> have chosen 4 for their state equivalents.
>


Actually, many countries do not have something like a "state equivalent",
it is a particularity of the USA because they are a federal republic.



>
> This level-skipping scheme extends all the way down to the smallest
> jurisdictions. Because the TIGERcnl import chose admin_level=8 for
> municipalities, skipping 7, I was able to tag Ohio townships as 7 without
> demoting all the state's cities and villages. [2] Even though neighboring
> Kentucky and West Virginia lack a level of government between counties and
> municipalities, it makes sense to keep cities in most states at the same
> admin_level, because they're functionally equivalent. (Virginia is a
> notable exception.)
>


I was not going to get into discussion about cities and other lower level
admin entities. Please lets stick to the state question.



>
> For context, there's an open pull request to have the Standard stylesheet
> render country and state labels based on administrative boundary polygons
> rather than place nodes. [3]
>


yes, this is also something I wanted to point to, because in the discussion
for this style change it was argued that some countries, which currently do
use level 3, should change that to level 4 (like the US), and I was arguing
the other way round, that the US should probably change the states to level
3 instead.



>
> Martin, how would the U.S. would be affected by this change? As it stands,
> U.S. state boundaries and labels appear at z4 and above, regardless of the
> state's size. Of the smallest states, Rhode Island (RI) appears at z4 and
> z6+, Connecticut (CT) appears at z4+, and Maryland (MD) and Delaware (DE)
> are both obscured at z4 by the label for Washington, D.C.
>
> At a glance, this change would seemingly omit most of the Northeastern
> states' labels at z4.
>
It appears to set a minimum size of 750 "way pixels" at z4 and 3,000 at z5
> for displaying a state's label. I don't really see those states' two-letter
> refs as being clutter.
>


I am not sure why raising the importance would lead to less names
displayed. If this holds true, the stylesheet would have to adopt to
correct this IMHO.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] admin level for US states

[Martin Koppenhoefer]

2014-11-24 18:05 GMT+01:00 Brad Neuhauser :

>  ...and German states and Swiss cantons are admin_level=4 according to the
> previously-linked page.



yes, I am coming from a German-Italian perspective, where Italian "regions"
are clearly less sovereign than German "states", which again are less
sovereign than US american states (all on level 4 currently).
We need the levels 5 to 10 in Germany (all are in use, 3 is not in use).
Correspondance of European entities should also be supported by the NUTS
and LAU system:
http://en.wikipedia.org/wiki/Nomenclature_of_Territorial_Units_for_Statistics
http://en.wikipedia.org/wiki/Local_administrative_unit

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] admin level for US states

[Martin Koppenhoefer]

I wonder why US States are tagged as admin_level=4, wouldn't it be more
consistent with the rest of the map to have them tagged as level 3?

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Ghost Towns

[Martin Koppenhoefer]

2014-11-18 18:41 GMT+01:00 stevea :

> Martin Koppenhoefer writes:
>
>> The latter example shouldn't probably be mapped in OSM, as there is
>> literally nothing left now, while the former is still there, it is simply
>> degraded by the water and not visible most of the time due to the lake.
>>
>
> Another like your latter example, here in Silicon Valley.  Lexington
> reservoir is where a usually submerged ghost town (one of several of these
> former small communities around this mountainous area) re-appears during
> prolonged droughts.



nah, that's like my former example (the first one), my second one (which
I'd not expect to see in OSM any more) was a former village where now there
is just a huge hole (open pit mining), i.e. they dug away everything until
depths of several hundred feet, like here:
http://de.wikipedia.org/wiki/Tagebau#mediaviewer/File:Tagebau_Garzweiler_Panorama_2005.jpg

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Ghost Towns

[Martin Koppenhoefer]

2014-11-17 15:27 GMT+01:00 tshrub :

> Generally if a structure is gone, I would delete it.
>


yes, but it is mostly difficult to say "it is gone", because most cases
aren't that absolute then this. If you search for "Heuersdorf" in osm,
you'll only get a hit by "geonames" (SCNR).
http://www.openstreetmap.org/search?query=Heuersdorf#map=13/51.1165/12.3976&layers=D


But (I think) the data alloyed into OSM's mind.
> So may be in *future*, you can see a landscape-animation. That would be
> funny.
>


yes, this is what I am also interested in. Have a look at OHM (open history
map), a branch of OSM. Unfortunately, as it stands now, you can't tell if
something is added to osm because
a) there was an error that got corrected
b) something was missing (in OSM) and now got inserted
c) the object is new in the real world and OSM caught up.
d)...

this could be modelled with changeset tags of course, but to make sense it
would require a lot of people using these tags and being disciplined in
structuring their edits into changesets.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Ghost Towns

[Martin Koppenhoefer]

2014-11-14 21:44 GMT+01:00 tshrub :

> Am 14.11.2014 19:15, schrieb Jack Burke:
>
>> What about submerged ones? Do we bother with those?
>>
> if we stumble over them, why not
>
> and it sounds for my as if those
> towns are still structures of reality
>


yes, another example is this one in Tuscany, It, which is normally
submerged in a lake, but will come to light every 10 years or so when the
lake is dried out for maintenance of the dam:
http://rete.comuni-italiani.it/foto/2009/61975

Situations like this:
http://www.gruene-bundestag.de/typo3temp/pics/e6d0cd2a32.jpg
 are very different, in that nothing of the original landscape (or village)
remains (this is open pit mining of lignite in Saxony, Germany, or more
precisely a place called "Heuersdorf" close to the mine "Vereinigtes
Schleenhain" pic taken 09-02-2009). Another image here:
http://www.fotocommunity.de/pc/pc/display/17845958

The latter example shouldn't probably be mapped in OSM, as there is
literally nothing left now, while the former is still there, it is simply
degraded by the water and not visible most of the time due to the lake.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] User randomly adding speed limits across the US

[Martin Koppenhoefer]

2014-11-11 11:02 GMT+01:00 Minh Nguyen :

> where the speed limit suddenly jumps from 25 to 55 at a village limit.
>



not sure if you are aware of this, in Europe we are mapping those village
limits (with the tag "traffic_sign=city_limit" and sometimes additionally
with name=placename) in order to better track speed limits. We'd typically
put the city_limit sign on the right side of the highway (it is not
intended for automatic data consumers but more a help for human mappers),
and not on the highway, to preserve implicit direction information.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Ghost Towns

[Martin Koppenhoefer]

2014-11-10 6:07 GMT+01:00 Hans De Kryger :

> Anyone know if we map ghost towns in osm? Couldn't find anything, not even
> a tag.
>


I think there should also be a place tag, e.g. place=locality (for a
generic uninhabited place), but that is really generic so something more
specific (AFAIK yet to introduce) would make sense as well.


cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Tagging a seasonally closed roads with uncertain spring opening

[Martin Koppenhoefer]

> Am 03.11.2014 um 16:03 schrieb Richard Weait :
> 
> seems access=seasonal isn't in wide use but would be correct


I think that this is not so nice tagging as it doesn't say anything about which 
season you'll be allowed to access. I would suggest conditional access, see the 
wiki for more info, it is something like access:conditional=no @ winter (I'm on 
mobile and didn't check this syntax)

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] Fresno castradal imports

[Martin Koppenhoefer]

Sorry for warming up this thread, I found it because I was looking for
additional information after I found distorting statistics in taginfo.
Please note that this import has significant impact on the world wide
statistics for all objects with landuse=residential tags. There are lots of
tags that we really don't want in OSM (e.g. the area size of an object,
which is already implicitly present by the geometry). Keeping this in OSM
is encouraging other mappers to use these tags.

Can we agree on batch removing tags like
http://taginfo.openstreetmap.org/keys/fresno_lot_area
or other_use, primary_use and secondary_use tags with cryptic values like
"000" or "S01"? http://taginfo.openstreetmap.org/keys/secondary_use#values
We really don't want to hold a complete, untransformed, copy of a public
database like the one imported here, do we?

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] changeset 25081346 spanning contiguous United States

[Martin Koppenhoefer]

2014-10-06 18:33 GMT+02:00 Peter Dobratz :

> I don't think that sweeping changes like this across large geographic
> areas should be made without communication of some kind.



Yes, you are right, there are also guidelines/policies for this kind of
edit, which do indeed require consultation with the comunity:
http://wiki.openstreetmap.org/wiki/Automated_Edits
http://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
http://wiki.openstreetmap.org/wiki/Mechanical_Edit_Policy

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Statistics of board candidate edits

[Martin Koppenhoefer]

> Il giorno 03/ott/2014, alle ore 21:23, Randal Hale 
>  ha scritto:
> 
> It has nothing to do with being on the OSM US Board. I was on it for two 
> years..we discussed editing, Neither of which had any bearing on that 
> candidates experience with editing.


if you are discussing editing it will surely help in the discussion  to have 
edited yourself ;-)

would you ask a catholic priest about raising kids? You'd surely get an answer, 
but it will remain highly theoretical;-)

cheers 
Martin 
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Statistics of board candidate edits

[Martin Koppenhoefer]

> Il giorno 03/ott/2014, alle ore 20:13, Darrell Fuhriman  
> ha scritto:
> 
> There are many, many ways that someone could be experienced with OSM and a 
> valuable contributor while never having made a single edit.


I'm not sure, how would someone  know what it is about without having done it?

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Help with revert : Drag moved street in Denver

[Martin Koppenhoefer]

> Il giorno 23/set/2014, alle ore 10:08, Bryce Nesbitt  
> ha scritto:
> 
> What might have caused the original issue?



no idea, possible reasons include un glueing connection nodes or deleting the 
last way segment before the connection (in Josm shift click in delete mode)


cheers 
Martin 
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Help with revert : Drag moved street in Denver

[Martin Koppenhoefer]

2014-09-23 8:29 GMT+02:00 Bryce Nesbitt :

> The original edit dragged a road, disconnecting at multiple points.




usually disconnections shouldn't happen by a simple drag. At least in JOSM
(but I believe also in the other editors), you'd have to actively
disconnect the nodes.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Speed limit sign tagging

[Martin Koppenhoefer]

> Il giorno 20/set/2014, alle ore 03:13, Nate Wessel  ha 
> scritto:
> 
> Which street does a sign right at an intersection belong to? I'm not sure how 
> best to deal with that.


I've been mapping signs for some years, in the very most cases the positions 
aside the highway are unambiguous, in rare cases close to intersections I had 
to slightly move the sign closer to its highway for the avoidance of doubt. 
When there are different limits on different lanes there is a general problem 
with this approach but fortunately this occurs almost never in my context

cheers,
Martin 
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Merging NYC buildings

[Martin Koppenhoefer]

2014-09-19 18:26 GMT+02:00 Paul Norman :

> but if I survey it and it's one building, I will map it so.
>


Does this survey include the inside or will the judgement be based only on
the outside?



>
> In dense urban areas the edges of buildings can often only be determined
> by surveys, not by imagery, as the imagery only shows the roofs generally,
> and roofs may change appearance within a building or not change appearance
> between two adjacent buildings.
>


Typically there will be some kind of division in the roof because you have
to avoid fire going from one building to the other.
I think it is more probable that people will split one building into
several buildings than the other way round.

It may also not be very clear how many buildings there are in some cases,
e.g. when dealing with very old buildings (i.e. not built according to
modern prescriptions), sometimes you will have dependent buildings (you
can't tear down one building because the neighbour would fall as well
because it is leaning on the other building, something that today won't be
allowed under any jurisdiction I am aware of).

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Prima Facie Speed Limits

[Martin Koppenhoefer]

2014-09-16 7:27 GMT+02:00 Greg Morgan :

> Woot! Woot!  If you are adding a speed limit to a node where a sign is
> located and if you add traffic_sign="maxspeed" along with your maxspeed="25
> mph", then JOSM will show you a cute little sign verses a blue dot.
> http://www.openstreetmap.org/node/147417922
>


I'm doing this and also adding traffic_sign=maxspeed to make clear that it
is a sign position. There is also an additional style for josm to display
the actual sign with the correct number (currently just for kph limits),
feel free to extend this for mph (eventually with the typical sign you have
over there):
http://josm.openstreetmap.de/wiki/Styles
http://josm.openstreetmap.de/josmfile?page=Styles/MaxspeedIcons&zip=1  (you
don't have to download it here to use it, you can activate this from inside
josm via preferences, styles)

cheers,
Martin

PS: one remark to "California vehicle code 22352"
This apparently stands for all kind of prima facie limits in California,
IMHO you could also use something more specific like "US:CA:school" where
"US:CA" would be a short form for
"California vehicle code 22352" and "school" one of the cases described in
this code (context). Would also be nice to document these here:
http://wiki.openstreetmap.org/wiki/Key:source:maxspeed
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Prima Facie Speed Limits

[Martin Koppenhoefer]

2014-09-15 16:59 GMT+02:00 Ed Hillsman :

> I agree there is a need to have a way to deal with this. Where I have
> checked a street, in both directions, for a posted speed limit and found
> none, I tag the street as maxspeed=unposted, source:maxspeed=survey. This
> makes it clear that the street has been checked in the field and found not
> to have a posted speed limit.



one problem I could see with that approach is that the information density
in your 2 tags is very low (the "unposted" value doesn't say anything about
the actual speed limit and the survey-value could be seen as implicit for
this kind of tag). IMHO putting an actual limit into the maxspeed key is
valueable, regardless whether this is signposted or an implicit limit,
because this is the speed information that most drivers on that road will
be interested in (typically).

Cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Prima Facie Speed Limits

[Martin Koppenhoefer]

I also suggest to add source:maxspeed=sign along with maxspeed=* to ways
with signposted maxspeed (especially when the sign posted speed equals the
default speed, because this will keep those speedlimits in place for the
case that the legislation changes and you'd want to update default speed
limits).

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Prima Facie Speed Limits

[Martin Koppenhoefer]

> Il giorno 14/set/2014, alle ore 06:34, Paul Johnson  ha 
> scritto:
> 
> Is it maxspeed:source or source:maxspeed?


"invented" as source:maxspeed and also most used

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Prima Facie Speed Limits

[Martin Koppenhoefer]

> Il giorno 10/set/2014, alle ore 20:15, Tod Fitch  ha 
> scritto:
> 
> The more I think about it, tagging each way is a bit like "(incorrect) 
> tagging for the router", basically creating a maintenance headache and 
> cluttering the OSM database with stuff the current router and navigation 
> guidance can use without being changed.


from my experience here, adding the maxspeed source (implicit from setting/ 
explicit from sign) really improves the maintenance situation. Also mapping 
sign positions helps a lot.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Prima Facie Speed Limits

[Martin Koppenhoefer]

2014-09-09 17:47 GMT+02:00 Martijn van Exel :

> I'm of the opinion that wherever the speed limit is just the default for
> that road class, it should not need to be posted at all. Any data user can
> then infer limits.



I don't know how this is handled in the US, but in Europe you will
definitely need explicit speed limits because there is no road class in OSM
that represents the needed properties. In Germany and Italy (and likely in
many other countries as well) for instance there is a distinction between
"inside settlement" and "outside settlement". Now not all residential roads
are inside a closed settlement, and not every settlement is considered a
settlement for the purpose of this law. The actual limits get set by the
city_limit signs, which do not correspond to actual settlement boundaries
but are put where the traffic planners think you should slow down (i.e.
even if we mapped places in osm in all instances as areas, this place area
would not correspond to the area with "urban" city limit).

Besides this, there is another issue: when a key in osm is missing, you
will not know if it is missing (here maxspeed), you will not know if it is
missing or if the default should apply.

Both are IMHO strong arguments to map also "default" (i.e. implicit, not
sign-posted) speed limits, while the dataconsumers (e.g. routers), will of
course need default values for road classes, especially for the cases of
missing maxspeed information.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Prima Facie Speed Limits

[Martin Koppenhoefer]

Am Montag, 8. September 2014 schrieb Tod Fitch :

>
> How does this sound?
>


+1

Cheers,
Martin


-- 
Martin Koppenhoefer (Dipl-Ing. Arch.)
Via del Santuario Regina degli Apostoli, 18

00145 Roma

|I|I|I|I|I|I|I|I|

Italia
N41.851, E12.4824

tel1: +39 06.916508070
tel2: +49 30 868708638
mobil: +39 392 3114712
mobil: +49 1577 7793740
m...@koppenhoefer.com
http://www.koppenhoefer.com


Hinweis:
Diese Nachricht wurde manuell erstellt. Wir bemühen uns um fehlerfreie
Korrespondenz, dennoch kann es in Ausnahmefällen vorkommen, dass bei der
manuellen Übertragung von Informationen in elektronische Medien die
übertragenen Informationen Fehler aufweisen. Wir bitten Sie, dies zu
entschuldigen.

Any views or opinions are solely those of the author and do not necessarily
represent those of koppenhoefer.com unless specifically stated.
This email and any files attached are confidential and intended solely for
the use of the individual or entity to which they are addressed.
If you have received this email in error, please notify
postmas...@koppenhoefer.com

Please note that to ensure regulatory compliance and for the protection of
our clients and business, we may monitor and read messages sent to and from
our systems.

Thank You.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Dirt Roads (formerly: Abandoned railway)

[Martin Koppenhoefer]

> Il giorno 06/set/2014, alle ore 23:41, Bryce Nesbitt  
> ha scritto:
> 
> The concept of hierarchy still exists for hiking trails, motorcycle routes, 
> paths, stairs, walkways.


For stairs, walkways and paths I am not so sure, usually when walking you'll 
take the shortest way, or the most beautiful, or the one that is best suited 
for the current weather conditions, or the one with the least mosquitoes, etc


Cheers,
Martin___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Dirt Roads (formerly: Abandoned railway)

[Martin Koppenhoefer]

> Il giorno 06/set/2014, alle ore 15:19, Tod Fitch  ha 
> scritto:
> 
> I think yes is better in response to Bryce's comment.


yes, yes to all but the cited passage of motorcycle width tracks ;-)


> 
> BEGIN RANT
> My view is that highway tagging conflates use and importance to the community 
> with physical properties. 


we generally want to avoid this, but I agree there is the width exception for 
ways that are too narrow for double tracked vehicles which makes it a little 
bit less stringent

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Dirt Roads (formerly: Abandoned railway)

[Martin Koppenhoefer]

> Il giorno 06/set/2014, alle ore 07:24, Bryce Nesbitt  
> ha scritto:
> 
> BUT ANY OF THESE can be primary, secondary, tertiary or residential. 


No, the ones that are too narrow (motorcycle) can only be path in osm

Cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Abandoned railway

[Martin Koppenhoefer]

> Il giorno 30/ago/2014, alle ore 10:33, Richard Fairhurst 
>  ha scritto:
> 
> Russ Nelson wrote:
>> I fear that the deletionism infection has jumped from Wikipedia 
>> to OpenStreetMap.
> 
> ...is exactly what I was going to say.
> 
> Seriously, OSM in the US, outside a few cities, is still way beyond broken.
> You can open it at any random location and the map is just fictional. (I
> did, just now: http://www.osm.org/edit#map=13/36.1938/-103.6446 . Half of
> those roads don't exist at all, and the other half are barely roads,
> certainly not residential ones as tagged.) Why would you (contentiously)
> delete railway=abandoned for an actual abandoned railway trackbed when the
> map has thousands, millions, of fictional or entirely mistagged roads and
> tracks?


+1, completely agree. Even if you don't care for abandoned railways and 
question their belonging in OSM, please respect others who actually do care. 
Deleting what someone has entered with great effort (and what is correctly 
tagged) will surely cause more harm than good to OSM as a whole (eg will 
frustrate and ultimately draw engaged mappers away from OSM).

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] More road name expansion thoughts

[Martin Koppenhoefer]

> Am 23/lug/2014 um 05:10 schrieb Serge Wroclawski :
> 
> I also like the
>   idea sign_name tag. If you build a routing engine, you might want
>   to show the sign name as it appears on the street,



as a side note there are already few occurrences of signed_name but none of 
sign_name
It is worth considering that there might be more than one sign, sometimes with 
different text (multivalue on the highway and/or map it on nodes at the sign 
location)

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Mapping Space Ports

[Martin Koppenhoefer]

2014-07-15 18:01 GMT+02:00 Eric H. Christensen :

> > The launch_pad could be tagged aeroway=launch_pad
> > There seem to be 7 aeroway=launchpad in the current db:
> > http://taginfo.openstreetmap.org/keys/aeroway#values
>
> I hadn't thought to look there.  The wiki doesn't seem to have anything
> regarding spaceports.  I'll start marking things up.




If you want to spare some time it would be nice to start documenting this
in the wiki (proposal et al). Btw., I'd prefer your suggestion "launch_pad"
(1x) and not the scarsely used "launchpad" (7x), as the latter is a brand
and the former is the correct spelling for the rocket take off thingy.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Mapping Space Ports

[Martin Koppenhoefer]

2014-07-14 19:38 GMT+02:00 Eric H. Christensen :

> I've not figured out the proper way to map a launch pad.




the whole complex could get some "spaceport" tag, e.g. man_made=spaceport
or aeroway=spaceport or amenity=...
The launch_pad could be tagged aeroway=launch_pad
There seem to be 7 aeroway=launchpad in the current db:
http://taginfo.openstreetmap.org/keys/aeroway#values

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] routing tags used by actual routing applications

[Martin Koppenhoefer]

2014-07-03 18:26 GMT+02:00 Kevin Broderick :

> Highway=service implies a private road, though;



AFAIK only some service like service=driveway are generally private=yes,
while parking _aisle, alley or generic service might be public roads.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] routing tags used by actual routing applications

[Martin Koppenhoefer]

2014-07-03 17:36 GMT+02:00 Brad Neuhauser :

> Just trying to process this: wouldn't a tracktype 1 be tagged as
> unclassified or residential anyway?  Or to ask a different way, assuming
> that roads with houses should be tagged as residential, when should one tag
> a sub-tertiary road as track vs. using unclassified?
>


You'd always tag it as unclassified, unless it is not a connection road and
is used only for agricultural / forestry purposes. If it is not a
connection road but used to access a certain building / facility, use
service.

E.g. this is clearly a track: http://binged.it/1odgrTZ
or this: http://binged.it/1j0zEud

in case of doubt I'd put unclassified ;-)

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] routing tags used by actual routing applications

[Martin Koppenhoefer]

2014-07-02 16:07 GMT+02:00 Kevin Broderick :

> IMO (based on both the wiki and what I've seen on the map), highway=track
> implies something that is not reasonably drivable by normal passenger cars
> at a normal rate of travel.



Actually this will depend on the setting, in Germany for instance, a
"track" is a legal class for a way that is legally not a road, but the
surface might be very good (asphalt, smooth) according to the region in
which it is. The reason for a track to be there is agricultural (or
forestry) use, so farmers will use them to access their fields. But they
are often also shortcuts for locals. You won't use them for long distance
travel, obviously, but if you have to choose between 1-2 km of track or 10
km of primary you'll probably choose the track. On the other hand, many
tracks are nowadays excluding regular motorized traffic with signs (in osm
there will be access-restrictions, so this is not a reason to exclude them
generally form routing).

Please remember that tracks are further sub-classed with the tag
"tracktype", where grade1 is a nice smoothly paved track, and down to
grade3 there should be no problem to use them with a regular car at medium
speeds.

I agree with you, if in doubt whether something is a track or an
unclassified road, choose the road. If it is a part of the road network, it
will never be a track.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] routing tags used by actual routing applications

[Martin Koppenhoefer]

> Il giorno 02/lug/2014, alle ore 01:36, Martijn van Exel  ha 
> scritto:
> 
> Added a comment to the discussion section of that page as well:
> https://wiki.openstreetmap.org/wiki/Talk:OSM_tags_for_routing#Authority.3F


I agree, maybe the best would be to delete this page? It contains some really 
old deprecated concepts like is_in and nothing unique that isn't documented 
elsewhere, AFAICS

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] routing tags used by actual routing applications

[Martin Koppenhoefer]

> Il giorno 01/lug/2014, alle ore 23:15, Jason Remillard 
>  ha scritto:
> 
> For example, scout does
> not route over highway=tracks, unless you are in pedestrian mode. It
> seems like a reasonable decision, perhaps all of the routers do this,


no, some routers do use tracks for car routing (I'd expect a router to use 
tracks for cars, but only as a last resort when there are no alternatives)

In your original post you mentioned path and cycleway, those should indeed not 
route cars


> but the wiki documentation says nothing of the sort, and it surprised
> me.


I'd file a bug at scout and see what they respond, you should definitely not 
adapt osm data based on one router

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] routing tags used by actual routing applications

[Martin Koppenhoefer]

> Il giorno 01/lug/2014, alle ore 20:15, Jason Remillard 
>  ha scritto:
> 
> Similarly to how default tile server shapes tagging, scout, skobbler ,
> osmand, etc, and the other widely used OSM routing applications will
> inevitably shape tagging. It would be useful to document what the
> mainstream routing application are actually doing rather than
> guessing.


OK for individual applications to document what they are (currently) using, but 
this is probably dynamic over time. From a mapping perspective you should 
describe the road network as best as you can to meet actual reality and not tag 
for a single application. Rather file a bug for scout or others to fix their 
rules if some correctly tagged road is not (yet) taken into account...

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Nominatim in CDP

[Martin Koppenhoefer]

2014-06-25 12:37 GMT+02:00 Minh Nguyen :

> "Postal cities" aren't currently tagged as areas, only tag values on
> individual POIs and buildings.



there is the key "postal_code" to be used on areas (and streets), I am not
sure if Nominatim evaluates it, but could be.
http://wiki.openstreetmap.org/wiki/Key%3Apostal_code

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Standard (mapnik) toolchain/processes: can we teach these better?

[Martin Koppenhoefer]

2014-05-26 12:07 GMT+02:00 Simon Poole :

> With a different hat on: yes it is a pet peeve of mine that we don't
> have a light weight way to push such information out to our contributors
> and, perhaps as a consequence, haven't developed a culture of actively
> informing before the fact.
>


+1
I think the german blog ("Wochennotiz") does a great job in filtering a lot
of interesting news about cartography, OSM, the mapnik style and a lot of
other things, and there is AFAIK also a translation by Pascal and Dennis of
the "main parts" (those potentially interesting an international audience)
into English (and some other languages) as well, called "Weekly OSM
Summary": https://blog.openstreetmap.org/
Not sure if the switch from rendering names as "catch all" to "selective
tags" was featured in the English version though. Anyway, a good read if
you are interested in OSM.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Fwd: Sidewalks as footpaths

[Martin Koppenhoefer]

> Am 09/mag/2014 um 01:09 schrieb Clifford Snow :
> 
> I wonder if a search for the nearest street would provide a clue to the 
> router? Not as exact as having either a named way or a relationship. 


IMHO we shouldn't advocate for a mapping method where you have to guess, rather 
then explicit mapping.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Sidewalks as footpaths

[Martin Koppenhoefer]

2014-05-08 17:46 GMT+02:00 James Umbanhowar :

> Could this problem be alleviated with a tag on the separately mapped
> footway, e.g. road_name?  Or even just addr:street?
>


why not make it simple and use "name"? As long as the sidewalk is part of
the road this would be correct.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Fwd: Sidewalks as footpaths

[Martin Koppenhoefer]

2014-05-08 16:32 GMT+02:00 Serge Wroclawski :

> 1. Why map sidewalks
>
> This is a judgement call. In NYC it's reasonable to assume that a road
> has a sidwalk. It would be better to map roads without sidwalks than
> roads with them, because a vast majority of roads have sidewalks.
>
> In DC, where I used to live, many roads did not have sidewalks, or
> only had sidewalks on one side of the street.
>
> Maybe where you are, it's closer to DC, or possibly even less. Or
> maybe you are trying to bright some light on the state of sidewalks in
> your area.
>


+1, generally I agree although there are more reasons, especially if you
want to record more than just sidewalk=yes/no, e.g. micromapping obstacles.
Where I live (not in the US) there are sometimes obstacles on the sidewalk
like bollards or there are very narrow spots (down to 30-40cm / 1ft) where
you have a hard time passing with a wheelchair or a babystroller. Mapping
these all to the main highway (=road) is problematic (you will get
complicated and direction dependent tags like footway:right:width) and will
require to split the road quite often in order not to apply the tag to road
sections where they don't apply to.

Also complex crossings can be mapped easier when explicit pedestrian
geometry is drawn, especially in situations where you cannot cross all
streets but only some.


cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Sidewalks as footpaths

[Martin Koppenhoefer]

2014-05-08 11:58 GMT+02:00 Serge Wroclawski :

> Being an American has nothing to do with a really bad data design.
> I've been an American 35 years and I think this is really not a good
> way to model sidewalks.
>


+1, agree, my main concern is that as pedestrian you can actually cross a
road at any point if it is not too much traffic and there are no other
rules forbidding it. Generally with explicity footways routing gets worse
in my experience because there mostly only few connections from the
sidewalk to the road mapped.
There is no way to distinguish separate footways (e.g. separated by a guard
rail) from those separated only by a curb. If mapping explicit sidewalks
there should also be some entity that ties all road lanes (and sidewalks)
together to one object.

On the pro side you can add surface, width and other information to where
they apply, while with tags on the main centre highway way you would have
to split the whole road for every change on the sidewalk (or any other of
its lanes).




>
> The problem (aside from the issue of data clutter) is that the
> sidewalk data can't be used for pedestrian routing because the
> information about the street is not captured. You can't tell someone
> to follow Main Street, because the path is not labeled as such.
>


well, you should either use a relation to tie them toghether, or add the
common attributes like name etc. to all elements (i.e. also to the
sidewalk).

In the end this is a question of detail, for very detailed mapping there is
a benefit IMHO in mapping sidewalks on dedicated objects, but I'd see this
more like explicit lane mapping, i.e. better use another tag than highway
for this in order to avoid confusion with indipendent footways.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Imports] "fleet manager" speed limit import proposal (Canada, USA)

[Martin Koppenhoefer]

2014-04-03 14:45 GMT+02:00 Richard Weait :

>
> Introduction:
> I have a source for posted speed limit data.  This thread begins the
> discussion of the data, the origin and quality of the data, and the
> suitability of the data to OpenStreetMap.
>


does it contain the positions of speed limit signs, or only the actual
limits for certain road segments?

Cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Why we really don't get new users

[Martin Koppenhoefer]

2014-03-18 1:32 GMT+01:00 Mike Dupont :

> On Mon, Mar 17, 2014 at 1:17 PM,  wrote:
>
>> The tagging of things bears little resemblance to things in the real
>> world:
>
>
> I agree, first of all, i tried to explain to someone how to tag a cafe/bar
> and he was confused and so was I.
>


amenity=cafe, is this really so difficult?



> why would americans want to learn british names for things?
>


actually they should learn "tags" (or use some abstraction layer like
presets) not "British names". If we all used tags in our native languages
it would maybe complicate stuff? Would be interesting to see what you wrote
if americans had to deal with German or Russian tags ;-)
You can translate this to a certain point, but you'll get more blur about
the meaning of a tag I guess, maybe up to the point where it gets useless,
but at least you'll loose the details. Ever read an automatically
translated appliance manual?

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike

[Martin Koppenhoefer]

> Am 17/mar/2014 um 02:28 schrieb Greg Morgan :
> 
> If I need to split a building, the original primary key does not stay with 
> one of the two pieces of the building.  Two new buildings are created with 
> two new primary keys.  


as a side note this is not like you described, the original way id will remain 
on one of the two pieces (at least with Josm you can also control which)

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Is the distinction between path and track dependent upon...

[Martin Koppenhoefer]

2014-03-10 16:54 GMT+01:00 Russell Deffner :

> Can we use motor_vehicle=restricted ?




Not sure what the meaning of "restricted" is, you can see all common values
on the access-page:
https://wiki.openstreetmap.org/wiki/Key:access

the common value for "you may generally not access unless you are
authorized" is "private" (can be used also on public land, what might be a
little confusing).

value Description  agricultural Only for agricultural traffic
customers
Only
for customers of the
element.[1]
[image: Ambox warning
pn.svg]Recent
addition with disputed applicability (See
discussion ).
Some mappers are using *"customer"* or "*destination*" instead; this
proposal 
describes
the
*customer* tag  delivery Only when delivering to the element.
designated
A
preferred or designated (not compulsory) route for a specific vehicle type
or types. Often marked by a traffic sign  destination Only when traveling
to this element, e.g. customer parking lots.  discouraged A legal right of
way exists (see "yes") but usage is officially discouraged (e.g. HGVs on
narrow but passable lanes) . Often marked by a traffic sign  forestry Only
for forestry traffic
no No
access for the general public. Consider using additional
*access:**=*tag(s) to indicate who
*can* use the element (e.g. if only specific transport
modesallowed).
official  The
way is dedicated to a specific mode of travel by law. Usually marked by
traffic signs and exclusive. In Germany use is also compulsory. *clarification
needed*  permissive
Open
to general traffic until such time as the owner revokes the permission
which they are legally allowed to do at any time in the future.
private Only
with permission of the owner on an individual basis  yes The public has an
official, legally-enshrined right of access, i.e. it's a right of way
cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Is the distinction between path and track dependent upon...

[Martin Koppenhoefer]

2014-03-10 16:36 GMT+01:00 Russell Deffner :

> should we just add access=non_motorized , or similar (not looking at
> the wiki to see if that's an actual tag).
>


the actual tagging is motor_vehicle=no / private (in the case of authorized
only). If different access restrictions apply to different modes of
transport it is generally better to tag the single restrictions and leave
the literal "access"-key void.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Is the distinction between path and track dependent upon...

[Martin Koppenhoefer]

2014-03-10 16:14 GMT+01:00 derrick nehrenberg :

> ...designated forms of travel or width of the trail?




it is generally width of the trail (if 4-wheeled vehicles can access
physically it is a track, if smaller a path). There might be some
exceptions though, if a path in the middle would be large enough also for
4wheeled vehicles, but it is only accessible passing (too) narrow parts. In
any case it is nice to have an explicit "width" tagged additionally.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] historic schools (amenity=school; name= * (historical)

[Martin Koppenhoefer]

2014-03-04 15:32 GMT+01:00 Serge Wroclawski :

> We don't store historical information in OSM. There are other projects
> which do, but OSM looks at what's currently in the ground.
>



yes, and no, we do store in small niches also historic information in the
main project, e.g. with the tags start_date and end_date, with the tag
old_name and variants of this tag, with the disused and abandoned tags etc.
A former school might also be an actual object, i.e. you might be able on
the ground to see that there is a school which is closed (hence
amenity=school doesn't fit, but disused:amenity=school or building=school
could be accurate descriptions of what is on the ground). To decide you
will have to know the area where you are mapping, deducting this from the
name tag of an import is most likely not very "ground-truthy" I agree.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] historic schools (amenity=school; name= * (historical)

[Martin Koppenhoefer]

2014-03-04 15:19 GMT+01:00 Theodin :

> OK. It says the same on the GNIS-Wiki-page so Im going to do that in the
> future. Although it might
> be a valid information for history-buffs to get an image of how things
> were.
>



I would only delete it if there is no building at all. Agree that it is not
an "amenity", but if a building is errected as school it will somehow be
recognizable (often) as such, i.e. the building type is still "school" even
if there is no school there (unless the building underwent heavy
restructuring / modifications).

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] historic schools (amenity=school; name= * (historical)

[Martin Koppenhoefer]

2014-03-04 11:38 GMT+01:00 Theodin :

> which are rendered on the map with their name. Are there any ideas for a
> better tagging as most of
> them (all?) arent really schools any more.
> I tagged some as
> historic=school
> which was in the database 80 times. Any better ideas?
>


they shouldn't be tagged as amenity=school if they aren't currently used as
school, and the name-tag shouldn't contain descriptions like
"(historical)". There are several possibilities to deal with this, probably
also depending on the situation (e.g. how long it is that there was an
actual school).

On way is to use prefixes, e.g.
disused:amenity=school

or abandoned:amenity=school
etc.

this is preferable over adding a attribute like disused=yes as the latter
would provoke misinterpretations (if you don't search for these status
attributes), a risk that is circumvented with the prefix.

Another way is to simply tag the building as what it is and don't use any
amenity at all, e.g.
building=school (= this is a building of the building type school)
name=* (should be the name of the building in this case, as name always
refers to where it is attached to)
etc.

you can of course also use historic=school but I would personally prefer
one of the two ways described above, the first for not so long closed
schools and the second for the rest.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Aerial Imagery for Chittenden County, VT

[Martin Koppenhoefer]

> Am 13/feb/2014 um 05:15 schrieb Andrew Guertin :
> 
> [1] I've withheld the URL as they haven't publicized it and I don't want to 
> be the cause of their server being hammered, but if you have some use for the 
> original data, let me know.


if they offer a WMS service we  could add a bookmark to Josm directly (and 
automatically give people editing in the covered area a popup about the 
availability of this source)

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Merging a GNIS node with a TIGER way - for a town

[Martin Koppenhoefer]

> Am 29/gen/2014 um 20:14 schrieb Sebastian Arcus :
> 
> I assume a place doesn't need to have both a node and a way.


Actually having both a node and a polygon is the best. If you delete either 
you'll loose information.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Fwd: [OSM-talk] Using 'Kort' outside of Switzerland

[Martin Koppenhoefer]

2014/1/18 Peter Davies 

>  Would it depend on (say) whether or not the street is actually posted in
> Japanese as well as in English?  Or should another criterion be suggested?



the name tag is not only about street names. Think of famous monuments or
important cities, they will more often have names in different languages.
Outside of multilingual areas it will be very rare that a street or square
has more than one name. There are also examples for the latter, like "St.
Peter's Square" in the Vatican City, which is according to the posted sign
called "Piazza San Pietro" (and there is no English name anywhere near or
at that square that I am aware of, but I guess nonetheless nobody would
doubt the validity of the English name.)

Other examples where multiple names for streets do occur are former
colonies, but one might argue that those are indeed multilingual areas.

For transliterations of non-latin characters I'd suggest to use a dedicated
tag and not the name:en etc. tags, but I'd use the name:en when the name is
also posted in English.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Finding deleted objects, WAS Re: what happened to the Mt. Hood National Forest?

[Martin Koppenhoefer]

2014/1/17 Dion Dock 

> BTW, how does one find an area that was deleted?



there are a series of tools and ways to achieve this. You can

a) find the object ID (nodes, ways and relations) in an older file (e.g. by
downloading it and cutting it to a small bounding box so you can open it in
JOSM), then use this ID to ask the main API about the way, e.g.
http://www.osm.org/way/42
b) use Potlatch1 (it is still there, although hidden, simply click on
"edit"-> Potlatch2 and remove the "2" from the url. Then zoom to the place
you are looking for a way (nodes and rels don't work) and hit "u" (you have
to wait a bit, deleted ways will show up in red).
c) use Whodidit http://zverik.osm.rambler.ru/whodidit/
d) browse changesets for deletions
...

Aside from the fact that in your case the object was not deleted but some
other error occurs, it is often good to analyze who has deleted a certain
object, as it might be a case of vandalism and the user might have deleted
more objects. With the ID you will find the changeset and the user and can
do this kind of lookup.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Feature Proposal - RFC - Marijuana

[Martin Koppenhoefer]

2014/1/3 Russell Deffner 

> Maybe more so if you are in Colorado, as sales of Marijuana to adults (for
> recreation/any use) began the morning of the first.  Therefor I propose the
> usage of shop=marijuana for this new business, have created a wiki-page for
> the proposal -
> http://wiki.openstreetmap.org/wiki/Proposed_features/Marijuana, and will
> leave it open for a commenting period of no shorter than two weeks.
>
>
>


the proposal is quite specific, you write: "a shop that is a State or other
licensed facility allowed to sell marijuana for recreation use."
not sure if those two requirements (license and recreation use) are
fundamental. What about a shop that sells marijuana in an area where no
license is required, or a shop that sells it for religious use? Maybe you
could go without them (e.g. "a shop selling primarily marijuana") or choose
your alternative wording (any use instead of recreation).

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Tags to use for chain stores in the United States

[Martin Koppenhoefer]

> Am 11/dic/2013 um 21:26 schrieb Richard Welty :
> 
> a walmart super center
> consists of a walmart discount department store, a walmart supermarket, and
> a suite of the various in store services. i think you need a separate node
> because - citizen's bank, pizza hut, nathan's hot dogs, etc. you should
> identify
> the vendors providing the in store services because who they are can matter.


are these different from a shopping mall? Maybe that's a new class like 
shop=super_center (or is this a brand?) or superstore or ...
Or maybe an attribute to supermarket?

Cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Tags to use for chain stores in the United States

[Martin Koppenhoefer]

2013/12/11 Brad Neuhauser 

> Personally, I tag "big box" stores like Target, KMart, WalMart etc with
> shop=department_store, just because that seems like the closest fit that
> isn't too restrictive (they're much more than a supermarket, to my mind).
>


a supermarket can sell a lot of stuff that is not food and still remain a
supermarket, e.g. the bigger ones might also sell clothing or some consumer
electronics (tv, pc). A department_store has lots of stuff and lots of
salesclerks serving you.

kmart vs.
http://www.flickr.com/photos/72294117@N03/7645650440/in/photolist-cDBXvj-dq7UY1-ePHTru-bzJeq-bzJiD-cLqWVb-cLqV7E-cLr1dJ-9HVd61-93H2Bi-fqvVSW-fqgRhp-fqgCZF-fqvSz9-fqgDvH-9XxowN-cDBZdU-cz73B1-8pPW7V-gvtUD5-gvtG83-7MJmWf-7MJoSQ-7MEupg-7MJuo7-7MJoKf-7MEpki-7MJrKW-7MEmRp-7MEmtr-7MEB4M-7MJtrd-7MJn5G-7MEBMa-7MEmAt-92tyfy-ePJ3xs-gvubH6-akA57y-ekk8vZ-cgQsed-7Zsd71-cXAMRY-cXAL4q-cXAHio-cXAJiQ-asWMnp-buguzF-bugtMt-c4vfy9-8m1Xv1

department stores:
http://commons.wikimedia.org/wiki/File:Central_Department_Store_ZUM_Sofia_20090406_007.JPG
http://commons.wikimedia.org/wiki/File:Harrods%27_Egyptian_room.JPG
http://upload.wikimedia.org/wikipedia/commons/0/03/Paris_Lafayette_inside.jpg
http://commons.wikimedia.org/wiki/File:KaDeWe_Deli.JPG

generally a department_store has more of the pricier stuff or at least
tries not to appear too cheap, while a supermarket tries the opposite:
appear as cheap as possible. Also a supermarket will have a huge parking in
front of it, while a department store will be found in the city center and
will have an underground or parking deck.

For those you name I think they would be better classified as supermarkets.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] South Carolina State Highways - primary overload

[Martin Koppenhoefer]

2013/12/11 Evin Fairchild 

> I think the reason why things like this happen is because the highway
> tagging scheme in OSM was modeled off of UK's road-classification system
> and really isn't compatible with the road-classification system in the US.



it is mainly the names that are taken from the UK classification. Every
road system is compatible with the current system, you simply have to
structure the data according to relative importance of the road (i.e. an
unclassified is less important than a tertiary which is less important than
a secondary than a primary). If you need additional attributes (like
state-highway) this doesn't necessarily have to be expressed in the main
highway tag. E.g. in Germany there are some streets that despite not being
a motorway have an additional sign which restricts usage to certain
motorized vehicles (no small motorcycles, no pedestrians, no bikes etc.)
and we detached this from the main highway classification and add an
additional motorroad=yes to these.

If "state-highway" means that maintenance is done by the state you could
also use "operator=*" for these (or maybe you can already see this property
by the "ref" tag?).

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] South Carolina State Highways - primary overload

[Martin Koppenhoefer]

2013/12/9 Shawn K. Quinn 

> Even weirder:
>
> http://www.openstreetmap.org/#map=13/34.3071/-80.9977
>
> is this stretch of SC 34 that goes primary-secondary-primary for no real
> reason I can see.
>


+1, this one should probably be primary.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] South Carolina State Highways - primary overload

[Martin Koppenhoefer]

2013/12/9 James Mast 

> There is no way almost all of the State Highways in SC can be "primary".
> Just look at almost any other state.  None are overloaded with primaries.



+1, also there are almost no secondary highways which also seems strange.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Separate relations for each direction of US & State highways.

[Martin Koppenhoefer]

2013/12/5 Martijn van Exel 

> I think the unsigned_ref practice is so common here that we should
> just keep that practice. Perhaps also a good one to document on the
> wiki.
> http://wiki.openstreetmap.org/wiki/Highway_Directions_In_The_United_States
> may not be the best place for it unless we want to make this page
> cover the broader scope of highway designation and signage in the U.S.
> (which I think would be great! but also would require a bit of
> dedication and time..)
>


+1, maybe it could be a country-specific section or be linked from here:
https://wiki.openstreetmap.org/wiki/Tag:route%3Droad

and probably be added also here: https://wiki.openstreetmap.org/wiki/Ref

pages like "bla bla in the united states" should be reduced to a minimum to
reduce inconsistent tagging between countries (they tend to evolve, like
also the "main system" evolves, and sooner or later they get "out of sync").

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Currently available good GPS for use with OSM mapping in the USA?

[Martin Koppenhoefer]

2013/11/29 Joseph R. Justice 

> I looked at the following items mentioned in the set of responses: The
> Garmin eTrex series (most specifically the 30; if one is going to get it,
> might as well get the best one available); the Columbus V-900 (and V-990);
> the AMOD AGL3080; the iBlue 747proS someone sent an Amazon link to.
>
> I skipped the other Garmin units mentioned (GPSMAP 62 et al) due to the
> lack of GLONASS support;
>


+1, maybe they are going to release a modernized model of that series in
the near future (would be due if they haven't decided to drop this series
completely)? They also do have very small (but great) displays, sooner or
later they will update this?




> The AMOD and iBlue seem too basic; I could only use them to upload data to
> my PC since they don't seem to have Bluetooth to communicate with Android
> devices.
>


Not sure for your iBlue model, but the 747A+ (and maybe others) does have
bluetooth.



>   No display or anything so I can't really use them as a standalone device
> except purely to record data.
>


+1



>
> The Columbus units seem to be somewhat interesting.  The 900 one at least
> has Bluetooth (the manufacturer's pages for the 990 don't mention it, at
> least that I can find).  However, I'm a little put off by what some people
> wrote about their relative lack of accuracy; I figure if I'm getting a GPS
> for the purpose of using it for OSM, accuracy is a significant
> consideration.
>


+1, I've also heard similar rumours.



>
> The major lack to the eTrex 30 is that it doesn't appear to have
> Bluetooth, so I don't think I can use it directly with my Android devices.
>


+1, but also keep in mind that your Android devices usually will have a GPS
(?) (sufficient to display a map more or less where you are, but not the
best for logging tracks) and that you will have much longer operating times
with one set of (standard) batteries on the (dedicated) GPS, so



>
>
> The other units non- eTrex units Garmin currently has with GLONASS support
> (Monterra, Oregon 600, 600t, 650, 650t) are all substantially more
> expensive than any of the eTrex units, so I think they're out of my budget.
>


AFAIK those are all touch-devices, which I wouldn't suggest for a GPS unit,
dedicated buttons are better (they do have a slightly better screen
resolution but do suffer (as far as I have heard) from less readable
screens in outdoor conditions.


Cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Separate relations for each direction of US & State highways.

[Martin Koppenhoefer]

2013/11/30 Peter Davies 

> So we have way ref I 394 instead of I 394;US 12.  For my applications I'd
> prefer it said I 394;US 12, because we need to track the overlaps (which we
> and our 10 state DOT customers call double banding).  But if you also want
> to suppress shields from maps in such areas, could we enter the way ref as
> I 394;US 12|unsigned  ?
>


Usually you would have (at least) 2 relations, one for each ref. The way
ref (if set at all) will often have multiple values, semicolon separated.
Not sure if you have a different agreement in the US, but it doesn't matter
if the ref is signed or not, as long as you can find it in some kind of
publicly available documentation (with compatible licensing).

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Currently available good GPS for use with OSM mapping in the USA?

[Martin Koppenhoefer]

2013/11/26 Richard Welty 

> the eTrex units seem to be much more accurate than the entry level
> auto units from Garmin. i'm intrigued though, by Martin's description
> of the 60CSx (which appears to have been replaced in the Garmin lineup
> by the 62CS).
>


I'm not sure if I won't go for the etrex20 as well, both use standard
AA-batteries, both have a low resolution screen but well readable in direct
sunlight, but the etrex has additional Glonass functionality.

Not sure how much quality improvement the Glonass capabilities give, but
I'd want them when buying a new GPS receiver ;-)



> if the good tracks are on the microSD card then that
> means you can minimize cycles on the mini-USB port, as you can
> remove the microSD and use an external reader. this should lead to
> a longer useful life for the unit (yes, i'm really fed up with having
> two dead Nuvis because of busted mini USB ports).
>


yes, being able to take them out is an advantage. Some recent models also
do wireless transmission I think.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Currently available good GPS for use with OSM mapping in the USA?

[Martin Koppenhoefer]

2013/11/26 Dion Dock 

> I've used a Garmin GPSmap 60CSx.  I think it records a point every
> second--or maybe it's every 5--I can't find the setting in the menus at the
>  moment.  Saving tracks to the micro SD card will strip off their
> timestamps and OSM rejects tracks without timestamps.  You could still
> trace them or import them with JOSM, probably.



I'm using this same unit. You can set the recording intervall in the track
recording page (I am using and promoting 1 second, there are also other
settings like per distance or less frequently but this only reduces
usefulness because stuff gets simplified and you get less "raw" data). I do
get the timestamps in the recorded track on the micro SD card, how do you
copy it? You have to mount the device as a disk and copy it like you would
with any other file (requires to set "record on card" in the device
settings from the tracks page, settings).

The track recording admittedly is a bit confusing, as you get the good
recording on the SD Card, but there is also a simplified (if you "save" it,
the "active log" is the same like the one on the SD card) trace on the
device's internal memory together with the custom way points. Both tracks
do have time stamp information if downloaded correctly (as gpx).

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Currently available good GPS for use with OSM mapping in the USA?

[Martin Koppenhoefer]

I'm using a Garmin GPS Map 60csx for years and do have very good experience
with it, it is now discontinued but the successor is still available (the
differences between the models is mostly the sensors: barometer or not,
electronic compass or not). You should be able to get something like this
for around 200USD:
http://www.amazon.com/Garmin-GPSMAP-Handheld-GPS-Navigator/dp/B003IHV6XW/ref=sr_1_2?ie=UTF8&qid=138549&sr=8-2&keywords=garmin+60csx
The advantages are long battery life (around 20 hours), screen readable in
the sunlight, rugged waterresistant device, "compatible" with osm maps
through mkgmap and precompiled maps. They do not have GLONASS compatibility
(AFAIK) and you should look for a model extendable via micro SD cards.

Another alternative I know some people who use it is this logger:
http://www.amazon.com/iBlue-747proS-Recorder-Motion-Sensor/dp/B00GIGMU76/ref=sr_1_3?ie=UTF8&qid=1385400286&sr=8-3&keywords=logger+iblue+747i
obvioulsy a cheaper solution (maybe you can this for around 50USD), but
isn't rugged, hasn't a screen and IMHO also worse reception (at least the
older model which I once compared to the Garmin handheld).

The osm wiki has a fairly nice (maybe partly outdated) comparison of
different devices with links to subpages:
https://wiki.openstreetmap.org/wiki/GPS_Reviews

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Separate relations for each direction of US & State highways.

[Martin Koppenhoefer]

2013/11/18 Nathan Mills 

> I'm still confused as to why the consumers of a relation can't use the
> forward/backward roles of the ways referenced therein rather than requiring
> completely separate relations. Why do we need two or more relations plus a
> super relation per road route even for undivided highways? Even for a
> somewhat experienced mapper like myself, it makes the editing process that
> much more error prone.


if the highway is never divided a single route would be sufficient (rather
hard to find this situation probably), but if you have routes that even for
a short way do not share the same geometry it will be easier to maintain
and to check if every direction has its own relation (and IMHO less error
prone).

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] take responsibility, not control.

[Martin Koppenhoefer]

2013/11/18 Richard Weait 

> Repair or revert data that is incorrect.  Get help from a
> more-experienced mapper if you haven't done this before.
>

Thank you Richard for this post. Very true that every single mapper can try
to make contact with other mappers in his surroundings and find a solution
for conflicts or teach them best practise or try to revert themselves
before putting the case on the national ML or asking DWG to revert.

On the other hand, when it comes to copyright infringements, you shouldn't
simply revert the edit but get it redacted, I guess? Otherwise the
infringements would be still contained in the full planet released by the
OSMF.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Ferries

[Martin Koppenhoefer]

> Am 08/nov/2013 um 18:15 schrieb Ivan Komarov :
> 
> I'd vote for introducing a new tag, that is highway=ferry_link, rather than 
> trying to use an existing one that does not describe the object correctly. 
> There used to be and there will be disputes on this topic unless we have it 
> fixed. Introducing a new tagging scheme will cause some issues for a while, 
> but on the long run it would work better, I believe.

+1

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Admin borders in the US

[Martin Koppenhoefer]

2013/11/7 Martijn van Exel 

> I would not dispute at all that administrative boundaries are an
> important component of any map. OSM is not really just a map though -
> it is a database you can make a map out of among many other things,
> and a very unique database at that: one created by people like you and
> me. The more data you introduce into our man-made OSM that is neither
> created nor verifiable by people like you and me, the more we depart
> from that notion of OSM as a map based on our collective knowledge,
> which is something that we should be very cautious about. And if you
> want to make that map, there are straightforward ways to incorporate
> things that live outside of OSM in it.
>


IMHO to some extend boundaries are also ground surveyable. Maybe you can't
do it up to the inch, but if you ask someone somewhere they could for
instance tell you whether they live in Canada or in the US. This might be
more difficult for borders in higher admin-level (numbers), but still it
could also work there. I don't expect this to be perfect, but with the time
my guess is that we would get to pretty good boundary data if enough people
take part.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Ferries

[Martin Koppenhoefer]

2013/11/7 Martijn van Exel 

> It's the other way around, really. We're adjusting our routing logic
> to adapt to OSM. Referring to the wiki, a service road is 'Generally
> for access to a building, motorway service station, beach, campsite,
> industrial estate, business park, etc.' - so by that definition, a
> service road would typically only occur at the beginning or the end of
> the route,
>


+1, there is also service=alley which some mappers use also in Europe, for
narrow alleys in medieval towns (usually you can't drive there with a car,
or hardly, but in Italy there is normally no restriction and you could
enter with a small car and many do so, and even more enter with
motorbikes). But still I agree, you won't use this for routing in the
middle of a route, it would only make sense to take these at the start or
end.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Complex intersection mapping

[Martin Koppenhoefer]

2013/10/15 Minh Nguyen 

> ** Example A **
>
> Ryans Way and Sycamore Grove Ln. meet Fields Ertel Rd. at the same
> intersection. Fields Ertel is undivided. Ryans Way is briefly divided at
> the subdivision entrance, a very common configuration in newer
> subdivisions, but Sycamore Grove is not.
>
> I mapped the intersection as a single point:
>
>  intersections/ryans_before.png
> **>
>
> Your colleague redrew it as a two-point intersection, dividing the very
> tip of Sycamore Grove (to the south):
>
>  intersections/ryans_after.png
> >
>
> I prefer the former approach, because the latter shows a false traffic
> island on the south side of the intersection. Imagine a pedantic navigation
> tool that tells a driver coming from Sycamore Grove to "keep/bear right and
> immediately turn left".
>


+1, before is better, after is "false" according to current conventions.



>
> ** Example B **
>
> A divided Main St. intersects a divided Remick Blvd. Like everyone else
> here -- and unlike the "before" example Martijn provided -- I prefer a
> four-point intersection. But just to the east, Remick and a service road
> both become undivided at the same intersection. I mapped it as a single
> point:
>
>  intersections/remick_before.**png
> >
>
> Your colleague redrew it as a four-point intersection, this time with two
> triangles:
>
>  intersections/remick_after.png
> **>
>



again before is better and after is problematic for the reasons you
described. The problem introduced in the after versions  is btw. the same
problem also existent in the after picture that Martijn showed in his
initial post (a single carriageway discharging into a dual carriageway
should not become itself a dual carriageway, in the original posting this
was the way coming from the east/right).

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Complex intersection mapping

[Martin Koppenhoefer]

2013/10/14 stevea 

> Hi Martijn:  one thing "wrong" I do see at this particular intersection
> are extraneous nodes with highway=crossing tags:  two extra ones on the
> (northerly) east-west ped-path and one extra one each of the (westerly and
> easterly) north-south ped-paths.  A fairly minor error in the context of
> your larger question.



+1, and another thing: the street coming from the right should not be
expanded to a dual carriageway at the point where your colleague has done
it, but rather at the latest possible point (i.e. at the first insection
with the N-S-road) if doing it this way.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Complex intersection mapping

[Martin Koppenhoefer]

2013/10/14 Martijn van Exel 

> So what are we talking about? Intersections like this one, where one
> or more dual carriageways come together at an at-grade intersection:
>
>
> https://www.evernote.com/shard/s9/sh/6438c196-bb92-4f66-81dc-9b75186286ba/0e8f07ff527c6a85c0dec426b9b79f1e
>
>

I think it is not only ugly and confusing but also pointless. If you insist
on distinguishing between physically separated / not separated carriageways
in the area of a crossing, it would be more straightforward (and a little
bit less confusing) to map this as in the attached screenshot.




> One of my colleagues at Telenav has remapped this intersection as follows:
>
>
> https://www.evernote.com/shard/s9/sh/3491f1fe-6afa-4571-bc43-7cb31c9c2625/9dd47d1445fdcf03d3f0bbd93b8e0f92
>


this is how we usually do in around here (Europe).

cheers,
Martin
<>___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Las Vegas region administrative areas

[Martin Koppenhoefer]

2013/10/11 Mike N 

> There was a good question posted in the forum that I can't quite come up
> with a solution or recommendation.
>
>   Re: place = locality in Las Vegas
>
> http://forum.openstreetmap.**org/viewtopic.php?id=22876
>


IMHO you'd tag place=town, name=Enterprise, as incorporated or not is an
administrative classification and belongs to boundary and admin_level, not
to place. place=locality is a tag not to be used for settlements or other
places where there are people living.

cheers,
Martin
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us