Re: [OSM-talk] amenity=Observatory OR amenity=astronomical_observatory

[Toby Murray]

With all the complaints about the amenity tag being overloaded already, this
seems like a good opportunity to avoid doing it more.

Toby

On Jan 9, 2011 5:35 PM, "Dave F."  wrote:

On 09/01/2011 21:06, marcellobil...@gmail wrote:
>
> Hi all, just a question for all the community w...
How are the mapped ones tagged?

Not saying it's correct but here's Mauna Kea:

http://www.openstreetmap.org/edit?editor=potlatch2&lat=19.82544&lon=-155.4728&zoom=16




___
talk mailing list
talk@openstreetmap.org
http://l...
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] address parsing by nominatim

[Vikas Yadav]

On 10 January 2011 00:45, M∡rtin Koppenhoefer wrote:

> 2011/1/9 ヴィカス ヤダヴァ (vikas yadav) :
> > I surveying from Northern India. I studied how addresses are to be tagged
> in
> > order so nominatim can locate it. That went great. The problem is the
> every
> > house has to be tied to a street (addr:street).
> > 1) We don't have names for living streets
>
>
> are you sure you are talking about living streets or do you mean
> residential streets?
>
>
> > 2) We so many times have blocks or sectors (tagged as locality or hamlet)
>
>
> locality should be used for uninhabited places
>
locality is the way i could properly render blocks and sectors right now in
OSM india. please suggest if there is a better/proper way achieving the same
render result.

z12: http://www.openstreetmap.org/?lat=28.408&lon=77.0776&zoom=12&layers=M
 - you can spot sectors (govt sold residential area) as well as private
societies (private sold resi are).

z14: http://www.openstreetmap.org/?lat=28.4141&lon=77.0564&zoom=14&layers=M
now, you can see blocks to sectors too like block A,B,C or Phase 1,2 or Part
1 or Part 2 which are within the same sector. (but there are no known naming
rules so there are always exceptions)
Only sometimes, street names are only connecting sectors. but never are
there street names within a sector.




>
> sorry, that I cannot help you with your original problem.
>
> cheers,
> Martin
>
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] highway=unsurfaced

[SomeoneElse]

On 09/01/2011 20:17, Dave F. wrote:

On 09/01/2011 16:28, Gorm E. Johnsen wrote:

Hi

Today there is >5500 ways with highway=unsurfaced...


Whilst the surface condition should be a sub-tag (surface=*), you 
unfortunately don't know what the actual road classification is, so 
it's inadvisable to do a mass change.


Does anyone know if there's a way to mass email the persons who tagged 
them that way & ask them to check & clarify?


I'm not sure that a mass email would be the complete answer, since 
presumably there would then be a conversation with at least some of the 
original mappers.  Far better to determine the active mappers with most 
affected ways and start at the top asking them if they can add the extra 
detail.


In a case like this, where something is imperfectly mapped, and there 
isn't an easy way to infer the extra detail, I really don't see the 
benefit of retagging.


Alternatively, perhaps Gorm could maybe create a page below his user 
page in the wiki divided the XAPI extra results that you've done by 
continent and country / state?  That way people who've recently been on 
one of the  "problem" roads might also be able to help.



___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] address parsing by nominatim

[Gregory Arenius]

It sounds like the current set of tags and structures in OSM don't properly
support what you're trying to do at the moment.  I think the best way to
deal with it would to propose some new tags so that these type of addressing
schemes can be properly supported in OSM with supporting documentation.

It sounds like you need some sort of block or sector tag you could set on
areas to define them properly.  A couple of other tags for addressing like
addr:block and addr:sector could then be added.

It would definitely take some time before they get supported by the
renderers and routers but I think that since a good sized chunk of the world
uses these types of addressing systems we should have an explicit way to
deal with them instead of trying to shoehorn them into a more European
system.  It will make it easier for mappers there to do things properly and
probably also make things work more reliably.

I don't have the experience with this type addressing to feel comfortable
doing any of that but if you put something up on the wiki people can use and
work on it.

Cheers,
Greg
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] App bar at cloudmade routingservice

[Maarten Deen]

Since a while now, cloudmade has some kind of app bar on the bottom of 
their routing map [1].
IMHO this is quite annoying as it takes up a whole chunck of the screen 
for which you get nothing worthwhile in return. Does anyone know how to 
remove this bar? I see no obvious methods. No x to close it, no settings 
to do.


[1] 

Regards,
Maarten


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] address parsing by nominatim

[vikas yadav]

Neither block or sector are OSM places. I have used halmet/locality and
suburb. by these, rendering is proper
if using the existing system could i propose addr:hamlet or addr:suburb
support?
Also, rendering probably is fine.
Its just how gazetteer/nominatim search algo that would require supporting
alternate tags.

Thanks,
Vikas

On 10 January 2011 15:34, Gregory Arenius  wrote:

> It sounds like the current set of tags and structures in OSM don't properly
> support what you're trying to do at the moment.  I think the best way to
> deal with it would to propose some new tags so that these type of addressing
> schemes can be properly supported in OSM with supporting documentation.
>
> It sounds like you need some sort of block or sector tag you could set on
> areas to define them properly.  A couple of other tags for addressing like
> addr:block and addr:sector could then be added.
>
> It would definitely take some time before they get supported by the
> renderers and routers but I think that since a good sized chunk of the world
> uses these types of addressing systems we should have an explicit way to
> deal with them instead of trying to shoehorn them into a more European
> system.  It will make it easier for mappers there to do things properly and
> probably also make things work more reliably.
>
> I don't have the experience with this type addressing to feel comfortable
> doing any of that but if you put something up on the wiki people can use and
> work on it.
>
> Cheers,
> Greg
>
>
>
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] address parsing by nominatim

[Jacek Konieczny]

On Mon, Jan 10, 2011 at 04:04:51PM +0530, ヴィカス　ヤダヴァ (vikas yadav) wrote:
>Neither block or sector are OSM places. I have used halmet/locality and
>suburb. by these, rendering is proper
>if using the existing system could i propose addr:hamlet or addr:suburb
>support?

And why not is_in:*, including recursive is_in:* (something has
is_in:suburb=something, something suburb has is_in:city=something_else,
etc), probably used together with addr:*? I know, that administrative
boundaries would often be better, but those are often not available.

Greets,
Jacek

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] address parsing by nominatim

[M∡rtin Koppenhoefer]

2011/1/10 Vikas Yadav :
> On 10 January 2011 00:45, M∡rtin Koppenhoefer 
> wrote:
>>
>> 2011/1/9 ヴィカス　ヤダヴァ (vikas yadav) :
>> > I surveying from Northern India. I studied how addresses are to be
>> > tagged in
>> > order so nominatim can locate it. That went great. The problem is the
>> > every
>> > house has to be tied to a street (addr:street).
>> > 2) We so many times have blocks or sectors (tagged as locality or
>> > hamlet)
>> locality should be used for uninhabited places
>
> locality is the way i could properly render blocks and sectors right now in
> OSM india. please suggest if there is a better/proper way achieving the same
> render result.


This is what we call "tagging for the renderers" = abusing a tag in a
way it is not describing what it is defined for, just because this
renders a nice picture. If you need another place-tag, that is not
documented here:

http://wiki.openstreetmap.org/wiki/Place

(e.g. place=block / sector or whatever), you "invent" it. You can use
all tags you like, but it is recommended for features of which you
think that they are valuable for other users as well, to document them
in the wiki (and maybe send a note to the mailing lists). Usually you
would make a "proposal".

cheers,
Martin

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] address parsing by nominatim

[M∡rtin Koppenhoefer]

2011/1/9 Elizabeth Dodd :

> Martin's reply highlights a problem with the eurocentric version of a
> place hierarchy in OSM - it doesn't fit India.


yes, seems like, but this doesn't imply you should abuse an
established tag with a different meaning. It should encourage you to
extend the current scheme with new values.

cheers,
Martin

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] App bar at cloudmade routingservice

[Tom Hughes]

On 10/01/11 10:22, Maarten Deen wrote:

> Since a while now, cloudmade has some kind of app bar on the bottom of
> their routing map [1].
> IMHO this is quite annoying as it takes up a whole chunck of the screen
> for which you get nothing worthwhile in return. Does anyone know how to
> remove this bar? I see no obvious methods. No x to close it, no settings
> to do.

Isn't this a question you should be addressing to Cloudmade rather than
the OSM community?

Tom

-- 
Tom Hughes (t...@compton.nu)
http://compton.nu/

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] address parsing by nominatim

[Brian Quinion]

> 2) We so many times have blocks or sectors (tagged as locality or hamlet)

OK - this sounds like a combination of bad tagging and software
problems with nominatim and the mapnik style sheet.

Can I suggest that locality and hamlet are probably not the correct
tags and that you need to come up with a consistent way to tag these
types of features.  Once there is a valid tagging scheme support can
be added to nominatim.

The suggestion of place=block or place=sector and addr:block,
addr:sector sound like a good direction to go.

So

1) they need to be documented on the wiki
2) discussed to look for any problems - for instance do they work in
other countries with similar problems?
3) a sample area needs to be tagged
4) software tools need to be extended to support the new tags.

This can potentially be done quite quickly - and using tags which do
not overlap with existing tags makes this a LOT simpler!

--
 Brian

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] address parsing by nominatim

[vikas yadav]

I used hamlet for my block as pop limit of <1000 is given = satisfied
I used suburb for it is neither a village or a town but holds 2 ~ 10 blocks
= suggest

We do have villages within cities and they have been tagged properly,
villages never have sub areas or blocks.
Therefore, sectors are not villages.

On 10 January 2011 16:35, Brian Quinion
wrote:

> > 2) We so many times have blocks or sectors (tagged as locality or hamlet)
>
> OK - this sounds like a combination of bad tagging and software
> problems with nominatim and the mapnik style sheet.
>
> Can I suggest that locality and hamlet are probably not the correct
> tags and that you need to come up with a consistent way to tag these
> types of features.  Once there is a valid tagging scheme support can
> be added to nominatim.
>
> The suggestion of place=block or place=sector and addr:block,
> addr:sector sound like a good direction to go.
>
> So
>
> 1) they need to be documented on the wiki
> 2) discussed to look for any problems - for instance do they work in
> other countries with similar problems?
> 3) a sample area needs to be tagged
> 4) software tools need to be extended to support the new tags.
>
> This can potentially be done quite quickly - and using tags which do
> not overlap with existing tags makes this a LOT simpler!
>
> --
>  Brian
>
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] App bar at cloudmade routingservice

[Maarten Deen]

On Mon, 10 Jan 2011 11:05:28 +, Tom Hughes wrote:

On 10/01/11 10:22, Maarten Deen wrote:

Since a while now, cloudmade has some kind of app bar on the bottom 
of

their routing map [1].
IMHO this is quite annoying as it takes up a whole chunck of the 
screen
for which you get nothing worthwhile in return. Does anyone know how 
to
remove this bar? I see no obvious methods. No x to close it, no 
settings

to do.


Isn't this a question you should be addressing to Cloudmade rather 
than

the OSM community?


I thought before I ask them, and since their service is probably 
frequently used by the community, maybe someone has already found a way 
and would like to share that knowledge.


Regards,
Maarten

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] address parsing by nominatim

[Pierre-Alain Dorange]

Vikas Yadav  wrote:

> locality is the way i could properly render blocks and sectors right now in
> OSM india. please suggest if there is a better/proper way achieving the same
> render result.
> 
> z12: http://www.openstreetmap.org/?lat=28.408&lon=77.0776&zoom=12&layers=M
>  - you can spot sectors (govt sold residential area) as well as private
> societies (private sold resi are).
> 
> z14: http://www.openstreetmap.org/?lat=28.4141&lon=77.0564&zoom=14&layers=M
> now, you can see blocks to sectors too like block A,B,C or Phase 1,2 or Part
> 1 or Part 2 which are within the same sector. (but there are no known naming
> rules so there are always exceptions)
> Only sometimes, street names are only connecting sectors. but never are
> there street names within a sector.

I've nor followed the whole discussion but perhaps can you test using
boundary relation. You can define area with name and nominatim use them.

relation
type=boundary
boundary=administrative
admin_level= ?

http://wiki.openstreetmap.org/wiki/Admin_level
it seems 6 for blocks

but the situation in India seems a bit tricky :
http://en.wikipedia.org/wiki/Administrative_divisions_of_India



-- 
Pierre-Alain Dorange
OSM experiences : 


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Semantics layer for tags

[Martijn van Exel]

Hi all,

There was a presentation about something like this at the last SOTM,
but I can't remember who did it. Please chime in.

I was talking to a friend just now about mobile editors for OSM and
soon enough the discussion shifted towards general usability issues
for OSM. A major one for me has always been the culture / language
dependency of the tags. Many of the longer threads on this list, and
also in real life talking about OSM, are about some form of 'how do I
attribute this?' A big part of why that question is so hard to answer
is in cultural and language differences. What constitutes a trunk road
in Lithuania? What is a chemist in Spain? Not all tags even translate
one to one. This will continue to be a challenge. As the range of
editors and contributors broadens, this challenge is going to be even
greater.

Ideally we would have a semantic layer between the user and the
database / API. This layer would comprise of an ontology of geographic
feature representations in different languages, think a structured
version of the different language versions of the Map Features page.
The ontology would also include synonyms of feature representations
(think chemist's vs pharmacy, motorway vs freeway vs highway). On top
of the ontology would be an interface allowing applications to present
the end user with features in their own language. This interface would
translate input in any language to a generalized classification for
insertion in the database.

A semantic layer would solve a lot of problems with tagging ambiguity,
break down language barriers, help create a cleaner database and
generally make OSM more accessible. It would not only be useful for
editing, but also for data representation on rendered maps as well as
navigation software.

Thoughts? Are we doing this already?

Martijn van Exel +++...@rtijn.org
laziness – impatience – hubris
http://schaaltreinen.nl | http://martijnvanexel.nl | http://oegeo.wordpress.com/
twitter / skype: mvexel
flickr: rhodes

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Semantics layer for tags

[M∡rtin Koppenhoefer]

2011/1/10 Martijn van Exel :
...> is in cultural and language differences. What constitutes a trunk road
> in Lithuania? What is a chemist in Spain? Not all tags even translate
> one to one.

> Ideally we would have a semantic layer between the user and the
> database / API. This layer would comprise of an ontology of geographic
> feature representations in different languages, think a structured
> version of the different language versions of the Map Features page.
> The ontology would also include synonyms of feature representations...

> A semantic layer would solve a lot of problems with tagging ambiguity,
> break down language barriers,

> Thoughts? Are we doing this already?


IMHO we are already doing something like this in our wiki, but the
main problems won't be solved hereby. The main problems are the
details ;-).

Of course you could have a list (or ontology) that says that
amenity=fuel would be de:Tankstelle, but it wouldn't tell you that you
can at almost all de:Tankstelle get compressed air for your bike, or
cigarettes at night, while in many other countries this is not a valid
assumption.

This is just an example, but you will have these assumptions for most
of the tags: for the local mapper they are included, but on a global
basis they won't be valid. The meaning of a tag is somehow always
dependent on the cultural background / area.

cheers,
Martin

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] amenity=Observatory OR amenity=astronomical_observatory

[Steve Bennett]

On Mon, Jan 10, 2011 at 7:24 PM, Toby Murray  wrote:
> With all the complaints about the amenity tag being overloaded already, this
> seems like a good opportunity to avoid doing it more.

Don't we have an amenity=research_centre? Make it a subtag of that, perhaps?

tl;dr: subtags, people!

Steve

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] highway=unsurfaced

[Alex Mauer]

On 01/09/2011 12:01 PM, Richard Fairhurst wrote:

No. highway=unsurfaced could be what's now commonly tagged as highway=track,
or highway=unclassified, or highway=bridleway. Only one of those three is a
road.


Which one were you thinking of?  I count two road types in your list: 
highway=track and highway=unclassified.  And it could be other highway=* 
types too.


It’s still better to use highway=road even if it turns out to be a 
bridleway, because highway=road is basically “we don’t know what it is, 
only that there’s something there; this needs to be (re-)surveyed”.


—Alex Mauer “hawke”


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Semantics layer for tags

[Martijn van Exel]

On Mon, Jan 10, 2011 at 2:50 PM, M∡rtin Koppenhoefer
 wrote:
> 2011/1/10 Martijn van Exel :
> ...> is in cultural and language differences. What constitutes a trunk road
>> in Lithuania? What is a chemist in Spain? Not all tags even translate
>> one to one.
>
>> Ideally we would have a semantic layer between the user and the
>> database / API. This layer would comprise of an ontology of geographic
>> feature representations in different languages, think a structured
>> version of the different language versions of the Map Features page.
>> The ontology would also include synonyms of feature representations...
>
>> A semantic layer would solve a lot of problems with tagging ambiguity,
>> break down language barriers,
>
>> Thoughts? Are we doing this already?
>
>
> IMHO we are already doing something like this in our wiki, but the
> main problems won't be solved hereby. The main problems are the
> details ;-).
>
> Of course you could have a list (or ontology) that says that
> amenity=fuel would be de:Tankstelle, but it wouldn't tell you that you
> can at almost all de:Tankstelle get compressed air for your bike, or
> cigarettes at night, while in many other countries this is not a valid
> assumption.

Yes, we're trying to maintain the wiki with language versions of the
Map Features, but that does hardly solve any problems of accessibility
that we're facing because different Things in reality are represented
and classified differently in different cultures and languages. A
semantic layer between the database and the API (or in the API) would.
It could even play a role in describing the implied attributes that
you are talking about - consider maxspeed defaults for example.

And no, ontologies are not magic wands. At least not Harry Potter
grade ones. They don't free us from having to think about editing, but
they would make it easier to provide a local culture / language
interface to OpenStreetMap editing.
>
> This is just an example, but you will have these assumptions for most
> of the tags: for the local mapper they are included, but on a global
> basis they won't be valid. The meaning of a tag is somehow always
> dependent on the cultural background / area.

Yes, that is exactly where a semantic layer would come in! For
example, I would tag a feature in a semantics-enabled JOSM in my
native language, Dutch, as "provinciale weg". A lookup in the ontology
would expose an ambiguity: a provincial road could be highway=primary
or highway=secondary, depending on the road number. Human
disambiguation would be required, the attributes of the semantic
relation between 'NL:provinciale weg' and 'highway=primary' and
'highway=secondary' could provide a clue to do this. In other cases,
it could be automated based on the context. For example, if the road
number was already entered by the user.

Many other cases would be non-ambiguous, I'm just picking an ambiguous
relation to explain how that could work.

Martijn

Martijn van Exel +++...@rtijn.org
laziness – impatience – hubris
http://schaaltreinen.nl | http://martijnvanexel.nl | http://oegeo.wordpress.com/
twitter / skype: mvexel
flickr: rhodes

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] talk Digest, Vol 77, Issue 26

[Richard Welty]

On 1/10/11 12:19 AM, John Smith wrote:

On 10 January 2011 02:04, Richard Welty  wrote:

not just in theory: George Washington Bridge, connecting NYC with
New Jersey. and it's not a minor bridge, it is rather a pretty significant
one in the traffic grid.

so you can't really dismiss the case as purely theoretical.

Is this another case of you trying to encourage tagging everything
instead of just the exceptions?


umm, i just provided a concrete example why the adjective
"theoretical" was not correct in characterizing Nathan's
concern.

i really don't see how you're getting from Point A to Point
B here.

richard


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] highway=unsurfaced

[Richard Fairhurst]

Alex Mauer wrote:
> Which one were you thinking of?  I count two road types in your list: 
> highway=track and highway=unclassified.  And it could be other highway=* 
> types too.

highway=track doesn't imply a road round here; clearly YMV.

> It’s still better to use highway=road even if it turns out to be a 
> bridleway, because highway=road is basically “we don’t know what 
> it is, only that there’s something there; this needs to be (re-)surveyed”.

In the UK there is absolutely no need to use highway=road. We have
high-resolution imagery (Bing) and reliable road classification data
(Ordnance Survey) for the whole of the country. You can reliably infer any
road type from these two sources, remembering too that OSM is an iterative
project and that a "best guess" with a fixme can always be improved upon.

Obviously I can't speak for (and don't really care about) your part of the
world, but I would consider a mass change of highway=unsurfaced to
highway=road in the UK as vandalism, and would take steps to revert it.

cheers
Richard


-- 
View this message in context: 
http://gis.638310.n2.nabble.com/highway-unsurfaced-tp5904655p5907804.html
Sent from the General Discussion mailing list archive at Nabble.com.

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Semantics layer for tags

[Ed Avis]

Martijn van Exel  rtijn.org> writes:

>> This is just an example, but you will have these assumptions for most
>> of the tags: for the local mapper they are included, but on a global
>> basis they won't be valid. The meaning of a tag is somehow always
>> dependent on the cultural background / area.
> 
>Yes, that is exactly where a semantic layer would come in! For
>example, I would tag a feature in a semantics-enabled JOSM in my
>native language, Dutch, as "provinciale weg". A lookup in the ontology
>would expose an ambiguity: a provincial road could be highway=primary
>or highway=secondary, depending on the road number. Human
>disambiguation would be required, the attributes of the semantic
>relation between 'NL:provinciale weg' and 'highway=primary' and
>'highway=secondary' could provide a clue to do this.

So you're saying that if some extra layer existed, you would be able to
add data to the map using natural language rather than following a tagging
scheme?  Or do you mean that different language communities would have their
own tagging schemes, with special values derived from their language (just
as current OSM tagging is derived from English), and an intermediate layer
would translate it?

Or maybe I have got the wrong end of the stick and the important issue is not
natural language but different classifications between countries, so that
the concept of a 'provincial road' exists in the Netherlands but is not an
official road classification elsewhere.  In that case, it would make most
sense even for Dutch-speaking users to tag it as highway=provincial_way
or another English-like tag scheme, to keep things consistent.

-- 
Ed Avis 


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] highway=unsurfaced

[Anthony]

On Mon, Jan 10, 2011 at 12:27 PM, Richard Fairhurst
 wrote:
>
> Alex Mauer wrote:
>> Which one were you thinking of?  I count two road types in your list:
>> highway=track and highway=unclassified.  And it could be other highway=*
>> types too.
>
> highway=track doesn't imply a road round here

Is there some well accepted definition of "road" that you're using to
make that statement?

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] talk Digest, Vol 77, Issue 26

[John Smith]

On 11 January 2011 03:21, Richard Welty  wrote:
> umm, i just provided a concrete example why the adjective
> "theoretical" was not correct in characterizing Nathan's
> concern.

I never said there were no exceptions, however they are just that,
exceptions not the rule which is what Nathan seemed to be getting at.

> i really don't see how you're getting from Point A to Point
> B here.

Based on comments you made in another thread where you were promoting
mass changes rather than just tagging exceptions.

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Semantics layer for tags

[Gianfra g]

Most of the things you are discussing about can be done in the LinkingOpenData 
(LOD) environment where you have ontologies dealing with almost every kind of 
human knowledge. In the LOD there are already several linguistic resources, 
some of them multilingual.I already developed and tested the feasibility of a 
SPARQL query expansion using linguistic resources published online.The main 
bottleneck between OSM and semantic web is constituted by the semantic 
translation of OSM itself.The OSM database looks poorly expressive semantically 
and the first semantic translation of OSM, LinkedGeoData already published in 
the LOD, while trying to overcome some deficiencies needs further development 
from my point of view.Gianfra

> To: talk@openstreetmap.org
> From: e...@waniasset.com
> Date: Mon, 10 Jan 2011 17:35:20 +
> Subject: Re: [OSM-talk] Semantics layer for tags
> 
> Martijn van Exel  rtijn.org> writes:
> 
> >> This is just an example, but you will have these assumptions for most
> >> of the tags: for the local mapper they are included, but on a global
> >> basis they won't be valid. The meaning of a tag is somehow always
> >> dependent on the cultural background / area.
> > 
> >Yes, that is exactly where a semantic layer would come in! For
> >example, I would tag a feature in a semantics-enabled JOSM in my
> >native language, Dutch, as "provinciale weg". A lookup in the ontology
> >would expose an ambiguity: a provincial road could be highway=primary
> >or highway=secondary, depending on the road number. Human
> >disambiguation would be required, the attributes of the semantic
> >relation between 'NL:provinciale weg' and 'highway=primary' and
> >'highway=secondary' could provide a clue to do this.
> 
> So you're saying that if some extra layer existed, you would be able to
> add data to the map using natural language rather than following a tagging
> scheme?  Or do you mean that different language communities would have their
> own tagging schemes, with special values derived from their language (just
> as current OSM tagging is derived from English), and an intermediate layer
> would translate it?
> 
> Or maybe I have got the wrong end of the stick and the important issue is not
> natural language but different classifications between countries, so that
> the concept of a 'provincial road' exists in the Netherlands but is not an
> official road classification elsewhere.  In that case, it would make most
> sense even for Dutch-speaking users to tag it as highway=provincial_way
> or another English-like tag scheme, to keep things consistent.
> 
> -- 
> Ed Avis 
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
  ___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Semantics layer for tags

[Peter Wendorff]

Am 10.01.2011 18:11, schrieb Martijn van Exel:

Yes, that is exactly where a semantic layer would come in! For
example, I would tag a feature in a semantics-enabled JOSM in my
native language, Dutch, as "provinciale weg". A lookup in the ontology
would expose an ambiguity: a provincial road could be highway=primary
or highway=secondary, depending on the road number. Human
disambiguation would be required, the attributes of the semantic
relation between 'NL:provinciale weg' and 'highway=primary' and
'highway=secondary' could provide a clue to do this. In other cases,
it could be automated based on the context. For example, if the road
number was already entered by the user.
I think, it's a good idea to think about semantic layers for OSM, but 
not for the editing side of the API.


There are a few issues where this would work - like the one you 
mentioned, like the translation of highway=living_street to 
"Spielstraße" in German or highway=pedestrian to "Fußgängerzone".
But there are a lot of other issues much more complicated - and on top 
of that much less unified in meaning.


A lot of threads here, at the tagging mailing list and so on show 
problems with the interpretation of a tag - even staying with some 
not-absolutely-defined-kind-of English as base language.
If you look at talk-de there are some threads about translation 
possibilities for JOSM presets.


I don't remember much issues there where it was perfectly clear how to 
translate any tag. Even drinking_water was discussed with multicultural 
scope to the definition of what water you can drink (with/without 
boiling it before).


I fear, the definition of any "official" layer dealing with the 
translation will make these misinterpretations even harder to resolve as 
I'm not pushed to think about the meaning of a tag before using it.


Providing something like that as a translation table or multilanguage 
ontology is nevertheless a good idea perhaps; to give developers a 
starting point for translation of features on the one hand, and for 
understanding of the implicit ontology the tagging builds.


regards
Peter

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] talk Digest, Vol 77, Issue 26

[Richard Welty]

On 1/10/11 12:59 PM, John Smith wrote:

On 11 January 2011 03:21, Richard Welty  wrote:

umm, i just provided a concrete example why the adjective
"theoretical" was not correct in characterizing Nathan's
concern.

I never said there were no exceptions, however they are just that,
exceptions not the rule which is what Nathan seemed to be getting at.


umm, the original discussion was about automated consolidation of
nodes with the same coordinates, either by bots or by routing
algorithms. Nathan was pointing out cases where this type of
consolidation was flawed in that correct mapping required nodes
with the same coordinates.

you dismissed this as theoretical.

i pointed out that it is not.

now you're transforming this from "theoretical" to an exception,
which is a different argument.


i really don't see how you're getting from Point A to Point
B here.

Based on comments you made in another thread where you were promoting
mass changes rather than just tagging exceptions.


not knowing which thread you're referring to, i have no way to
respond to this.

richard


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] highway=unsurfaced

[Alex Mauer]

On 01/10/2011 11:27 AM, Richard Fairhurst wrote:

Alex Mauer wrote:

Which one were you thinking of?  I count two road types in your list:
highway=track and highway=unclassified.  And it could be other highway=*
types too.


highway=track doesn't imply a road round here; clearly YMV.


Sounds like the usage is wrong “round there” then.  The example image on 
the wiki[1] clearly shows a road, and one which is pretty typical of a 
highway=track around here (green grassy field aside, given that it’s 
winter here)



Obviously I can't speak for (and don't really care about) your part of the
world, but I would consider a mass change of highway=unsurfaced to
highway=road in the UK as vandalism, and would take steps to revert it.


That seems quite extreme: while it might be better to do a 
best-guess+fixme, it’s not clearly “wrong” to change from one form of 
unknown road classification, to another form of unknown road classification.


—Alex Mauer “hawke”

1. 
http://wiki.openstreetmap.org/wiki/File:Fr%C3%BChlingslandschft_Aaretal_Schweiz.jpg



___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Semantics layer for tags

[Martijn van Exel]

(forgot to copy to talk)

On Mon, Jan 10, 2011 at 6:35 PM, Ed Avis  wrote:
> Martijn van Exel  rtijn.org> writes:
>
>>> This is just an example, but you will have these assumptions for most
>>> of the tags: for the local mapper they are included, but on a global
>>> basis they won't be valid. The meaning of a tag is somehow always
>>> dependent on the cultural background / area.
>>
>>Yes, that is exactly where a semantic layer would come in! For
>>example, I would tag a feature in a semantics-enabled JOSM in my
>>native language, Dutch, as "provinciale weg". A lookup in the ontology
>>would expose an ambiguity: a provincial road could be highway=primary
>>or highway=secondary, depending on the road number. Human
>>disambiguation would be required, the attributes of the semantic
>>relation between 'NL:provinciale weg' and 'highway=primary' and
>>'highway=secondary' could provide a clue to do this.
>
> So you're saying that if some extra layer existed, you would be able to
> add data to the map using natural language rather than following a tagging
> scheme?  Or do you mean that different language communities would have their
> own tagging schemes, with special values derived from their language (just
> as current OSM tagging is derived from English), and an intermediate layer
> would translate it?

The latter. The user would be able to tag a feature with "chemist",
"pharmacy", "farmacia or "apotheek" and that would result in the same
coding in the OSM database (currently: shop=chemist). When consuming
OSM data, the process could be reversed; based on the locale, a
feature tagged "shop=chemist" could (would) be output as being one of
these culturally determined Things. Note that a "chemist", a
"pharmacy", a "farmacia" and an "apotheek" are names for something
that is similar across cultures and languages, but not literally the
same.


> Or maybe I have got the wrong end of the stick and the important issue is not
> natural language but different classifications between countries, so that
> the concept of a 'provincial road' exists in the Netherlands but is not an
> official road classification elsewhere.  In that case, it would make most
> sense even for Dutch-speaking users to tag it as highway=provincial_way
> or another English-like tag scheme, to keep things consistent.

The idea is to *avoid* having different classifications on the
database level, even though one concept could be represented by two
different names in one language (consider freeway / highway). Any
ambiguity arising from that would have to be handled by additional
attributes.


Martijn van Exel +++...@rtijn.org
laziness – impatience – hubris
http://schaaltreinen.nl | http://martijnvanexel.nl | http://oegeo.wordpress.com/
twitter / skype: mvexel
flickr: rhodes

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Semantics layer for tags

[Richard Weait]

On Mon, Jan 10, 2011 at 8:25 AM, Martijn van Exel  wrote:
> Hi all,
>
> There was a presentation about something like this at the last SOTM,
> but I can't remember who did it. Please chime in.

You might be remembering David Earl's talk, "Tag Central"

Slides
http://wiki.openstreetmap.org/wiki/SotM_2010_session:_Tag_Central:_a_Schema_for_OSM

Video
http://vimeo.com/14776099

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Semantics layer for tags

[Martijn van Exel]

On Mon, Jan 10, 2011 at 7:29 PM, Richard Weait  wrote:
> On Mon, Jan 10, 2011 at 8:25 AM, Martijn van Exel  wrote:
>> Hi all,
>>
>> There was a presentation about something like this at the last SOTM,
>> but I can't remember who did it. Please chime in.
>
> You might be remembering David Earl's talk, "Tag Central"
>
> Slides
> http://wiki.openstreetmap.org/wiki/SotM_2010_session:_Tag_Central:_a_Schema_for_OSM
>
> Video
> http://vimeo.com/14776099
>

Yes, that is it! Thanks Richard! That was a both insightful and funny talk.

Martijn van Exel +++...@rtijn.org
laziness – impatience – hubris
http://schaaltreinen.nl | http://martijnvanexel.nl | http://oegeo.wordpress.com/
twitter / skype: mvexel
flickr: rhodes

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] highway=unsurfaced

[Richard Fairhurst]

Alex Mauer wrote:
> Sounds like the usage is wrong “round there” then.  The example image on 
> the wiki[1] clearly shows a road
> http://wiki.openstreetmap.org/wiki/File:Fr%C3%BChlingslandschft_Aaretal_Schweiz.jpg

I think if you described that as a "road" in the UK you'd have the Trades
Descriptions people onto you pretty sharpish. Maybe this explains why our
newspapers get so over-excited when satnavs direct us down bumpy,
inhospitable things and claim they're "roads". That would be described only
as a "track" here.

But it doesn't matter. There is simply no need to fiddle in this way. The
situation is just as it was last time Gorm tried to enforce his own idea of
tag tidiness
(http://lists.openstreetmap.org/pipermail/talk/2010-November/054639.html);
again, this change achieves nothing and is at risk of breaking plenty,
including every mkgmap .img based on its default styles.

A cursory glance suggests Britain appears to have more highway=unsurfaced
than other places, and even then there aren't that many. I will happily fix
200 of them _properly_ (i.e. with what the track actually is, not the
cop-out of highway=road) if someone creates a rendering to highlight where
they are. 

cheers
Richard

-- 
View this message in context: 
http://gis.638310.n2.nabble.com/highway-unsurfaced-tp5904655p5908118.html
Sent from the General Discussion mailing list archive at Nabble.com.

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] highway=unsurfaced

[john]

American usage would be to refer to that as a road, just not a very 
high-quality road.  I take it that, in Britain, there are certain minimum 
standards for being called a road?

---Original Email---
Subject :Re: [OSM-talk] highway=unsurfaced
>From  :mailto:rich...@systemed.net
Date  :Mon Jan 10 12:52:47 America/Chicago 2011



Alex Mauer wrote:
> Sounds like the usage is wrong “round there” then.  The example image on 
> the wiki[1] clearly shows a road
> http://wiki.openstreetmap.org/wiki/File:Fr%C3%BChlingslandschft_Aaretal_Schweiz.jpg

I think if you described that as a "road" in the UK you'd have the Trades
Descriptions people onto you pretty sharpish. Maybe this explains why our
newspapers get so over-excited when satnavs direct us down bumpy,
inhospitable things and claim they're "roads". That would be described only
as a "track" here.

But it doesn't matter. There is simply no need to fiddle in this way. The
situation is just as it was last time Gorm tried to enforce his own idea of
tag tidiness
(http://lists.openstreetmap.org/pipermail/talk/2010-November/054639.html);
again, this change achieves nothing and is at risk of breaking plenty,
including every mkgmap .img based on its default styles.

A cursory glance suggests Britain appears to have more highway=unsurfaced
than other places, and even then there aren't that many. I will happily fix
200 of them _properly_ (i.e. with what the track actually is, not the
cop-out of highway=road) if someone creates a rendering to highlight where
they are. 

cheers
Richard

-- 
View this message in context: 
http://gis.638310.n2.nabble.com/highway-unsurfaced-tp5904655p5908118.html
Sent from the General Discussion mailing list archive at Nabble.com.

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

-- 
John F. Eldredge -- j...@jfeldredge.com
"Reserve your right to think, for even to think wrongly
is better than not to think at all." -- Hypatia of Alexandria
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Semantics layer for tags

[Ed Avis]

Martijn van Exel  rtijn.org> writes:

>The user would be able to tag a feature with "chemist",
>"pharmacy", "farmacia or "apotheek" and that would result in the same
>coding in the OSM database (currently: shop=chemist).

Rather than typing in the name and hoping that it matches in the translation
layer, it would be better for the user to select it from a list.  It then
becomes an ordinary localization problem.  If the OSM editor program has a
set of choices with user-visible text for each, then existing translation
services such as Launchpad Translations can be used to localize them to
different languages.

>When consuming
>OSM data, the process could be reversed; based on the locale, a
>feature tagged "shop=chemist" could (would) be output as being one of
>these culturally determined Things. Note that a "chemist", a
>"pharmacy", a "farmacia" and an "apotheek" are names for something
>that is similar across cultures and languages, but not literally the
>same.

I don't fully understand what you mean.  If it all gets tagged the same way
on the map then a client program cannot distinguish between the German
apothecary and the Spanish pharmacy.  It would just be a language lookup
and not a culturally determined difference.

A residential street is not literally the same across cultures either, but
the different kinds have enough in common that they can all be tagged the same
way.  So I expect most amenities would be like that too.

>The idea is to *avoid* having different classifications on the
>database level, even though one concept could be represented by two
>different names in one language (consider freeway / highway).
>Any ambiguity arising from that would have to be handled by additional
>attributes.

This sounds very sensible and I think it is mostly the situation we have now.
What you are proposing is a more friendly interface to the OSM tags for non-
English speakers, rather than a change to the way tagging is done.  Is that so?

-- 
Ed Avis 


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Semantics layer for tags

[M∡rtin Koppenhoefer]

2011/1/10 Martijn van Exel :
> (forgot to copy to talk)
>
> On Mon, Jan 10, 2011 at 6:35 PM, Ed Avis  wrote:
>> Martijn van Exel  rtijn.org> writes:
> The latter. The user would be able to tag a feature with "chemist",
> "pharmacy", "farmacia or "apotheek" and that would result in the same
> coding in the OSM database (currently: shop=chemist).


amenity=pharmacy, dispensing=yes/no

 When consuming
> OSM data, the process could be reversed; based on the locale, a
> feature tagged "shop=chemist" could (would) be output as being one of
> these culturally determined Things. Note that a "chemist", a
> "pharmacy", a "farmacia" and an "apotheek" are names for something
> that is similar across cultures and languages, but not literally the
> same.
>
> The idea is to *avoid* having different classifications on the
> database level, even though one concept could be represented by two
> different names in one language (consider freeway / highway). Any
> ambiguity arising from that would have to be handled by additional
> attributes.


I fear that a system like that will soon become utterly complex, thus
disabling most of the mappers of taking part in the
"tag-development-process". It would shift the discussions away from
the ML and wiki to defining the semantic rule set. And still we would
have to have definitions in natural language to define what a feature
is about, so there is no guarantee that there won't be contradictions
or different tags with the same meaning.

I agree that it is a good idea to develop such a ruleset (or extend an
existing one like linked geodata) to make the usage of our dataset
easier (for developers), but I agree with you: it is not a magic wand.

cheers,
Martin

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Semantics layer for tags

[Martijn van Exel]

On Mon, Jan 10, 2011 at 6:51 PM, gianfranco gliozzo  wrote:
> Most of the things you are discussing about can be done in the
> LinkingOpenData (LOD) environment where you have ontologies dealing with
> almost every kind of human knowledge. In the LOD there are already several
> linguistic resources, some of them multilingual.
> I already developed and tested the feasibility of a SPARQL query expansion
> using linguistic resources published online.
> The main bottleneck between OSM and semantic web is constituted by the
> semantic translation of OSM itself.
> The OSM database looks poorly expressive semantically and the first semantic
> translation of OSM, LinkedGeoData already published in the LOD, while trying
> to overcome some deficiencies needs further development from my point of
> view.
> Gianfra

Gianfranco,

Can you elaborate on that last point you make? How is OSM lacking in
terms of semantic expressiveness?

Martijn van Exel +++ m...@rtijn.org
laziness – impatience – hubris
http://schaaltreinen.nl | http://martijnvanexel.nl | http://oegeo.wordpress.com/
twitter / skype: mvexel
flickr: rhodes

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] highway=unsurfaced

[Tom Hughes]

On 10/01/11 19:00, j...@jfeldredge.com wrote:


American usage would be to refer to that as a road, just not a very 
high-quality road.  I take it that, in Britain, there are certain minimum 
standards for being called a road?


Nothing official, but it would be very unusual for anybody to call 
something that wasn't surfaced a road.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Semantics layer for tags

[Gianfra g]

Yes Martijn there
are weak classifications, everything that is not mapped is not
represented in the database. For example the classification in five
groups of tags and in the subgroups in the map feature list is not
expressed in the database. OSM database is missing abstraction
levels.
Moreover all
tags are treated seamlessly, even when they are properties or
subclassifications.




Martin,
existing linguistic resources in the semantic web are able to
identify not only synonymy but almost all relation between concepts,
also some topological relation like partonomy (a thing is a part of
another).


Gianfra 




> Date: Mon, 10 Jan 2011 20:27:01 +0100
> From: dieterdre...@gmail.com
> To: m...@rtijn.org
> CC: talk@openstreetmap.org; e...@waniasset.com
> Subject: Re: [OSM-talk] Semantics layer for tags
> 
> 2011/1/10 Martijn van Exel :
> > (forgot to copy to talk)
> >
> > On Mon, Jan 10, 2011 at 6:35 PM, Ed Avis  wrote:
> >> Martijn van Exel  rtijn.org> writes:
> > The latter. The user would be able to tag a feature with "chemist",
> > "pharmacy", "farmacia or "apotheek" and that would result in the same
> > coding in the OSM database (currently: shop=chemist).
> 
> 
> amenity=pharmacy, dispensing=yes/no
> 
>  When consuming
> > OSM data, the process could be reversed; based on the locale, a
> > feature tagged "shop=chemist" could (would) be output as being one of
> > these culturally determined Things. Note that a "chemist", a
> > "pharmacy", a "farmacia" and an "apotheek" are names for something
> > that is similar across cultures and languages, but not literally the
> > same.
> >
> > The idea is to *avoid* having different classifications on the
> > database level, even though one concept could be represented by two
> > different names in one language (consider freeway / highway). Any
> > ambiguity arising from that would have to be handled by additional
> > attributes.
> 
> 
> I fear that a system like that will soon become utterly complex, thus
> disabling most of the mappers of taking part in the
> "tag-development-process". It would shift the discussions away from
> the ML and wiki to defining the semantic rule set. And still we would
> have to have definitions in natural language to define what a feature
> is about, so there is no guarantee that there won't be contradictions
> or different tags with the same meaning.
> 
> I agree that it is a good idea to develop such a ruleset (or extend an
> existing one like linked geodata) to make the usage of our dataset
> easier (for developers), but I agree with you: it is not a magic wand.
> 
> cheers,
> Martin
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk

  ___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] highway=unsurfaced

[Greg Troxel]

Anthony  writes:

> On Mon, Jan 10, 2011 at 12:27 PM, Richard Fairhurst
>  wrote:
>>
>> Alex Mauer wrote:
>>> Which one were you thinking of?  I count two road types in your list:
>>> highway=track and highway=unclassified.  And it could be other highway=*
>>> types too.
>>
>> highway=track doesn't imply a road round here
>
> Is there some well accepted definition of "road" that you're using to
> make that statement?

Yes, a public or private way.  Something that would be shown in a zoning
map as being a parcel.  Someting the public has a reasoable expectation
of driving on.  As opposed to track which is a way to drive on a piece
of property that is not a parcel.

In Mass this is a legal distinction.  IIRC drunk driving, speeding,
etc. on a public or private way is an offense, but your own driveway is
not such a way.   As in if an airport owner lets you drive to 100 on the
runway that's not speeding.  But if it's a "road" then it is, even if a
private way.

I think this is pretty clearly understood even if the boundary is
slightly hazy.



pgpKODeMn8EyI.pgp
Description: PGP signature
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] address parsing by nominatim

[Brian Quinion]

2011/1/10 ヴィカス　ヤダヴァ (vikas yadav) :
> I used hamlet for my block as pop limit of <1000 is given = satisfied
> I used suburb for it is neither a village or a town but holds 2 ~ 10 blocks
> = suggest
>
> We do have villages within cities and they have been tagged properly,
> villages never have sub areas or blocks.
> Therefore, sectors are not villages.

You seem  to be determined to force the existing tagging scheme onto a
situation for which is was not designed.  It as far better to use new
and appropriate tags that reflect the actual situation - software
support should follow fairly rapidly if you come up with a suitable
tagging scheme.

Using hamlets, villages and incorrectly named roads to try to hack the
various software will not work and is very unlikely to be supported by
any of the software.

Pierre-Alain Dorange's suggestion to use admin_level and some type of
boundary is another reasonable way to approach the problem - although
I would suggest that your probably want to create something like
admin_level=11 or maybe even 12.  6 Is definitely too low.

You may also be able to find inspiration in the tagging of Japan - my
understanding is that they have a similar approach and may already
have created a suitable scheme.

--
 Brian

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] How do I get higher-resolution imagery in JOSM?

[Alan Mintz]

At 2011-01-07 09:32, Grant Slater wrote:

On 7 January 2011 16:23, Toby Murray  wrote:
> What would be slick is if the blank tiles
> could be automatically detected and then previous imagery overzoomed
> instead of displaying the blank tiles.
>

Yes this was added yesterday to JOSM version #3774 or above.

http://josm.openstreetmap.de/changeset/3774/josm


Would someone then change the JOSM default max zoom level to 22 (the max 
according to Bing API doc). This may explain why nobody responded that they 
were able to see zoom 21 or 22 imagery in their area when I asked the question.


BTW, the previous way to avoid the blank tiles was to turn off auto-zoom 
(right-click on image, uncheck auto-zoom) once you figured out where the 
max zoom was. The new solution is much better, of course.


--
Alan Mintz 


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] How do I get higher-resolution imagery in JOSM?

[Alan Mintz]

At 2011-01-07 06:43, Nathan Edgars II wrote:

Both Yahoo and Bing have nice imagery in the Orlando area:
http://www.openstreetmap.org/edit?lat=28.417946&lon=-81.491858&zoom=20
http://www.openstreetmap.org/edit?editor=potlatch2&lat=28.417946&lon=-81.491858&zoom=20
But I cannot get JOSM to load this quality. Is there a trick I'm missing?


In the case of Yahoo, the max resolution available via JOSM is a poor 
1.6m/pel (160m zoom level in JOSM) because of the API we're allowed to use. 
The other APIs (including that supported by maps.yahoo.com) have access to 
higher zoom levels and the higher-res imagery.


--
Alan Mintz 


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Landsat WMS is dead

[Elizabeth Dodd]

On Mon, 10 Jan 2011 01:27:11 +0100
Chris Browet  wrote:

> Just out of curiosity, where is Landsat more detailed than Bing or
> Yahoo?
> 
> - Chris -

plenty of places near me
ie western NSW, australia

where there is no nearmap coverage nearmap then defaults to landsat, so
I am still using landsat

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] address parsing by nominatim

[Stephen Hope]

2011/1/10 ヴィカス　ヤダヴァ (vikas yadav) :
> I used hamlet for my block as pop limit of <1000 is given = satisfied

The problem here is that population is only part of the definition of
a hamlet.  Less than 1000 people is correct, but it also has an
implied "and is surrounded by open land/farms etc".  You can't have a
whole bunch of adjacent hamlets sharing borders, they are not hamlets.

Stephen

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk