Re: [Talk-cz] [Imports] CzechAddress Import

2014-03-26 Tema obsahu Dalibor Jelínek
Hi.

Well, I agree with Pieren.

Either the tags are necessary or they are not, it cannot be both.

As we are not “allowed” to import them then we will delete them. 

What’s the point of having them only on a some address points?

Also we plan to “re-import” all the address nodes in Czechia how do we tell

when to keep it and when to delete it?

Majority of the addresses were imported by “illegal” automatic imports

or using semiautomatic tools here in Czechia so there are not many tags 

which were created manually anyway.

 

Dalibor

 

 

From: Martin Koppenhoefer [mailto:dieterdre...@gmail.com] 
Sent: Wednesday, March 26, 2014 7:49 PM
To: Pieren
Cc: impo...@openstreetmap.org
Subject: [Spam] Re: [Imports] [Talk-cz] CzechAddress Import

 

 

2014-03-26 15:40 GMT+01:00 Pieren mailto:pier...@gmail.com> 
>:

On Wed, Mar 26, 2014 at 3:20 PM, Martin Koppenhoefer

> you should not do this. Please do not automatically delete tags that were
> entered manually.

I think there is a large consensus that some tags like "addr:country"
are redundant. Adding them is not detrimental but removing them too. I
don't see the point why a redundant tag becomes suddently untouchable
and sacred just because it was added manually...

 

+1, I agree for addr:country, which is not helpful unless you are very close to 
the border (in which case it might have its sense), but he was also listing 
explicitly addr:city and addr:suburb.

cheers,
Martin

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz


Re: [Talk-cz] [Imports] CzechAddress Import

2014-03-25 Tema obsahu Dalibor Jelínek
Hello,
so, after a long debate here at imports mailing list, Czech mailing list 
talk-cs and with Serge Wroclawski, 
we have reduced our tagging plans considerably to comply with the request not 
to import anything which could be expressed using border polygons.

Therefore we will not import:
addr:suburb (neither addr:borough)
addr:city
addr:country
These tags will be used only in rare cases where the address node lies outside 
of its respective polygon border.

We will even erase these tags from existing address nodes during the import as 
we want to have all Czech addresses in the same format.

We simply can not omit adding addr:place as it cannot be expressed by the 
border polygon. It is vital for searching by Nominatim in small villages where 
there are no street names. It would be very handy if Nominatim could search for 
address in format "addr:place addr:housenumber" even when the addr:streetname 
exists but this is another topic.

We would have to import suburb borders in the future as they do not exist now.

The English description page about our import was updated to reflect current 
plan:
http://wiki.openstreetmap.org/wiki/Import_adres_z_RUIAN

We believe that there is nothing stopping us from beginning the import now.
If you think otherwise then please let us know. 

Thank you.

Regards,
 Dalibor (chrabros)

> -Original Message-
> From: Sarah Hoffmann [mailto:lon...@denofr.de]
> Sent: Thursday, March 13, 2014 7:53 AM
> To: p...@propsychology.cz
> Cc: impo...@openstreetmap.org
> Subject: [Spam] Re: [Imports] [Talk-cz] CzechAddress Import
> 
> On Wed, Mar 12, 2014 at 11:28:01PM +0100, Petr Vejsada wrote:
> > Dne St 12. března 2014 21:31:38, Martin Koppenhoefer napsal(a):
> >
> > > This means you can add the name of the administrative district, but
> > > you do not have to, it still remains a valid and unambiguous
> > > address. IMHO you shouldn't tag this district to every housenumber.
> > > "Vinohrady" is redundant information in this case and not necessary
> > > for the location to be found. Or are there maybe also other "130 00
> > > Praha 3 - xy" where xy is not "Vinohrady"? Also for Boleslavska?
> >
> > Aaaah, we are back again in the discussion about addr:place. It's
> > neverending...
> >
> > You're right, in _this_ case, address without Vinohrady is valid. But:
> >
> > - people knows, i'm living in Vinohrady. They usually don't know, i'm
> > living in Praha 3
> >
> > - Nominatim really cann't find the house without tag addr:place.
> > "Libochovany 129" or "Vinohrady 1989" - nothing found. It was my
> > primary motivation to run this import - posibility to find what i'm 
> > searching
> for.
> 
> Alas, that won't change after the import, at least for this particular 
> address.
> For technical reasons, Nominatim can only support either a street address or
> a conscription number. So, it will work fine in small villages that have only
> conscription numbers but not in Prague where there are both.
> But that is a missing feature in Nominatim.
> I believe that your tagging in this case is completely correct. The moment you
> add a addr:conscription_number tag, there should be an addr:place tag with
> the name of the place the number belongs to. Just like there should be an
> addr:street tag when addr:street_number is added. It has exactly the same
> function: relate the number to the object that determines the address.
> 
> > There is some redundancy, but i don't think enormous ...
> >
> > There is polygon of country boundaries - addr:country=CZ is redundant.
> > We explained several times, why to use this tag Yes, it's about
> > geocoders. It's a part of address.
> >
> > There are polygons of city boundaries - addr:city=* is redundant. City
> > is part of address.
> >
> > There are NO polygons of "cast obce", inexistant boundaries we can't
> > import into OSM - addr:place=* is not redundant. addr:place is not
> cadastral place.
> > addr:place is nececessary part of address, if there is no
> > addr:suburb/borough/...
> 
> addr:suburb/borough is not the same as addr:place. Please don't use one in
> place of the other. Always add addr:place. addr:suburb/borough is
> redundant in the same way addr:city is. Most of the time it can be
> determined from the boundaries. It is only really useful where the postal
> address differs from the admin boundaries. (Happens more often than one
> would like.)
> 
> If you still want to add it, addr:suburb should be sufficient, no need to 
> invent
> a new tag. I'd interpret 'suburb' here just as: the part of the address that
> describes a part of the city. And I believe that fits.
> 
> > Agree, it's a little bit diferent. This is amenity point, not address point.
> > Restaurant is in house (sometimes, garden restaurant is not) and the
> > house usually has their's own address point.
> >
> > > I don't even need to mention what borough (or county) the object is
> > > in for the same reasons.
> >
> > > Adding in the other fields is just a matter for a geo

Re: [Talk-cz] [Imports] CzechAddress Import

2014-03-10 Tema obsahu Dalibor Jelínek
Hi,
> Looking at the description on the wiki, the appropriate tag for what
you're
> describing is addr:suburb. addr:borough has 6 uses in the database.
Can you elaborate on this a bit more?
There was a heated discussion about this change in Czech and mainly Slovak
mailing list.
The main reasons are that Czech dictionary translation of borough is exactly
right for what it is = large self-governing district of a city. While suburb
translation is something like periphery.
As we are not allowed to use the key in Czech language, which would solve
the situation. Then we are stuck with closest English term which is borough
here.

Also we have two larger administrative units over our poposed borough and we
wanted to reserve suburb for one of them.

So we do not want to choose a key with a worse name just because it is used
more frequently at the moment somewhere in the world.

 > You're proposing changesets of 5 items per changeset. That's a
problem.
Well, we menat is as absolute maximum. As the file is reviewed by an
volunteer before import it is unlikely that this value would be ever
reached.
What value is acceptable?


> It's not clear from the wiki page how you plan to handle conflicts between
> OSM data and RUIAN data. OSM data should not be automatically be
> replaced.

The data are matched and if the match is good we generaly update missing
data.
If the data are not matched (differ significantly in house number or street)
we leave OSM data intact and ignore them. 
So the way is:
- find OSM data with the same address as we have in RUIAN and add the
missing info from RUIAN and RUIAN reference
- if there is no OSM data in close range then add new address point from
RUIAN
The whole import data are reviewed by an user before import.

Regards,
 Dalibor (chrabros)



> ___
> Imports mailing list
> impo...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz


Re: [Talk-cz] [Imports] CzechAddress Import

2014-03-10 Tema obsahu Petr Vejsada
Hi, All,

Dne Pá 7. března 2014 11:47:42, o...@propsychology.cz napsal(a):

> I made test import into my APIDB. There are four changesets at
> http://mapapi.propsychology.cz/user/pedro/history , everyone can check,
> if the data are merged properly.

Currently is our database offline. We're loading current osm data and preparing 
the DB for the import.

At this last moment, we decided to respect recomendation from this mailing 
list and we replaced tag suburb with tag borough. It's more accurate. We can't 
use tag district, because district is reserved for much bigger regions called 
"okres". Czech republic is divided to 77 "districts" or "okresu", but we don't 
use "district" (okres) in this import, because it's really not needed. 
Districts (okresy) have well defined boundaries and Nominatim can use them 
well.

We'll write notes about the import to discussion page at 
https://wiki.openstreetmap.org/wiki/Talk:Import_adres_z_RUIAN .

We expect to start the import on end of this week.

--
Petr


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz


Re: [Talk-cz] [Imports] CzechAddress Import

2014-03-07 Tema obsahu osm
Hi, All

On Thu, Feb 27, 2014 at 03:04:53PM +0100, Dalibor Jelínek wrote:

> Serge,
> really? I was not aware that I am importing anything.
> If you have those last three imports in mind, then I was
> merely tracing RUIAN a Cadastre map by hand.
> Is that an import?

Dalibor, I "imported" thousands of buildings from RUIAN also ;-))).

> But I have an unpleasant feeling that you are just try bullying me
> as I did not like your insensitive and offensive comments about the borders
> and history of my country.

It touches me also, i think, Czech republic exists for a longer time then OSM,
so ...
Let's stop this (off)-topic.

I made test import into my APIDB. There are four changesets at
http://mapapi.propsychology.cz/user/pedro/history , everyone can check,
if the data are merged properly.

We welcome _relevant_ comments. If the comments will be not relevant, we'll
start the import, because we fulfilled all requirements.

--
Petr

___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz


Re: [Talk-cz] [Imports] CzechAddress Import

2014-02-27 Tema obsahu Dalibor Jelínek
Serge,
really? I was not aware that I am importing anything.
If you have those last three imports in mind, then I was
merely tracing RUIAN a Cadastre map by hand.
Is that an import?
If yes, then it is what we do here in Czech Republic
since the Cadastre map was available. Which is a lng time ago.
So, if you think that this is an import, then please point me
to the definition of OSM import as I would like to check it.

But I have an unpleasant feeling that you are just try bullying me
as I did not like your insensitive and offensive comments about the borders
and history of my country.

Dalibor

> -Original Message-
> From: Serge Wroclawski [mailto:emac...@gmail.com]
> Sent: Thursday, February 27, 2014 2:06 PM
> To: Dalibor Jelínek; d...@osmfoundation.org
> Subject: [Spam] Re: [Imports] CzechAddress Import
> 
> Dailbor,
> 
> I see from your changesets
> (http://www.openstreetmap.org/user/chrabros) that  you are doing a
> building import. Can you point me to the wiki page and or imports
discussion
> on that building import, because I don't remember it.
> 
> - Serge
> 
> On Thu, Feb 27, 2014 at 8:02 AM, Serge Wroclawski 
> wrote:
> > On Wed, Feb 26, 2014 at 10:49 PM, Dalibor Jelínek 
> wrote:
> >
> >> We have added in to here
> >>
> >>
> http://wiki.openstreetmap.org/wiki/Import_adres_z_RUIAN#Background
> >>
> >> However these are Czech laws without English translation.
> >>
> >>
> >>
> >>> > Is it in the metadata? I did not see a link to the original data
> >>
> >>> > (only a search form), so it was hard to examine myself.
> >>
> >>
> >>
> >> We have added a link to sample XML file from RUIAN VDP
> >>
> >>
> http://wiki.openstreetmap.org/wiki/Import_adres_z_RUIAN#Background
> >>
> >>
> >>
> >>
> >>
> >>> > 2. Looking at the sample osm file you provided, I have a set of
> >>> > questions:
> >>
> >>> > a) I'm not familiar with addr:suburb. I see the wiki entry, but
> >>> > can
> >>
> >>> > you elaborate on this more, and why it's needed here?
> >>
> >> addr:suburb is a larger administrative division of a city, it
> >> contains several city quaters and it is used very often in reffering
> >> to a general directions in a city.
> >>
> >> We will create a wiki page for it later.
> >
> > If you want is as part of the import, it should be discussed during,
> > not after the import.
> >
> >> The vast majority of OSM users here have never heard of boundary
> relation.
> >> If we want to convince them that OSM is useful (i.e. generating POI
> >> files for navigation units) then we have to make the as simple as
possible.
> >
> > The vast majority of OSM users never need to know what relations are
> > at all, but it does not matter, since the tools they use will do the
> > right thing. We do not need to fill up the database with duplicate
> > data for no reason.
> >
> >> The source code is here
> >>
> >> http://pedro.poloha.net/osm/czechaddress-sql.zip
> >
> > All I see in that file is sql statements  for transforming the data
> > you've collected and managing it. I do not see any code related to how
> > you will:
> >
> > 1. Merge it with existing OSM data
> >
> > 2. Validate the data you have with ground truth
> >
> > Those are what I'm most concerned about. Please tell me how your
> > process will handle this validation step.
> >
> > - Serge


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz