On Fri, Feb 15, 2008 at 12:57:41AM +0100, Stefan Keller wrote:
model and will never evolve or be re-imported from other databases. Users
will be 'surprised' when they miss their data on the map like with 'Tunnel '
instead 'Tunnel' or with things like that '¨name'='Südstrasse'. My proposal
Look: It seems to be debate about unstructured, semi-structured and
structured data. What you're celebrating is something around semi-structured
data.
Marcus reminded my that OSM allows for a building to be more than just a
shop, but a gas-station a fuel-station, lit, car-wash, etc. That's right,
2008/2/15 Stefan Keller [EMAIL PROTECTED]:
Look: It seems to be debate about unstructured, semi-structured and
structured data. What you're celebrating is something around semi-structured
data.
Marcus reminded my that OSM allows for a building to be more than just a
shop, but a gas-station a
On Friday 15 February 2008 08:32:17 Stefan Keller wrote:
Marcus reminded my that OSM allows for a building to be more than just a
shop, but a gas-station a fuel-station, lit, car-wash, etc. That's right,
but keep in mind, that I *don't* propose to change the current internal OSM
schema and I
In the model I showed and I would use for such purposes a sample query would
look like this:
# select * from building'; -- was: where type='shop'
# select * from streets: -- where street type value can be anything
Where buildings get a building (= table = keyname) point symbol/style and
streets
It is no harder for me to add construcción(spanish) to the renderer than
So, you're after a running target? Not so in my example schema of exported
OSM data.
And finally all this just because being reluctant to restrict key names to
ASCII without space or so?
- S.
2008/2/15, Rob Reid [EMAIL
Stefan,
What exactly is the problem you're trying to solve ? It seems to me
you're on a mission:)
Here is what you should do:
A. If you have the skills, get the data and convert it into whatever
format/schema is good for you.
B. If you haven't got the skills, _fund_ someone to help you to
On Fri, Feb 15, 2008 at 01:53:43PM +0100, Martijn van Oosterhout wrote:
VALUES ( 3029222, 'LINESTRING()', 'key=value, key=value, ...' );
^^
I'm all for completely redoing the data model every once in a while but I'd
suggest that you prepare a complete proposal in
On Fri, Feb 15, 2008 at 2:22 PM, Gabriel Ebner [EMAIL PROTECTED] wrote:
On Fri, Feb 15, 2008 at 01:53:43PM +0100, Martijn van Oosterhout wrote:
VALUES ( 3029222, 'LINESTRING()', 'key=value, key=value, ...' );
^^
I'm all for completely redoing the data model
As Frederik Ramm got it, it's about this:
There is a reason why our data format has
tag k=keyname v=value /
instead of
keynamevalue/keyname
and that reason is allowing non-XML stuff in the key names. Or at
least it seems like that could have been a reason. I hope nobody's
going to come
On Feb 13, 2008 8:47 AM, Stefan Keller [EMAIL PROTECTED] wrote:
As Frederik Ramm got it, it's about this:
There is a reason why our data format has
tag k=keyname v=value /
instead of
keynamevalue/keyname
and that reason is allowing non-XML stuff in the key names. Or at
least it
On 13 Feb 2008, at 08:47, Stefan Keller wrote:
So to recap: The current allowable characters in OSM tag names is
UTF8 -
Deal with it, instead of trying to impose limitations into OSM to
make
OSM data comply with YOUR requirements.
It's not 'my' requirement, it's about best
On 13 Feb 2008, at 11:31, Stefan Keller wrote:
SteveC,
I acknowledge the argumentation of Jochen and Dave but I can't
follow yours.
As regards me, you're still welcome to join the technical discussion.
Well that's kind of the point, OSM isn't a technical project. Mapping
parties aren't
Sorry, are you sure, you're on the right list here?
I thought this was the OSM-developers list.
S.
2008/2/13, SteveC [EMAIL PROTECTED]:
On 13 Feb 2008, at 11:31, Stefan Keller wrote:
SteveC,
I acknowledge the argumentation of Jochen and Dave but I can't
follow yours.
As regards me,
On 13 Feb 2008, at 19:12, Stefan Keller wrote:
Sorry, are you sure, you're on the right list here?
Yeah... I think so... I think I even had something to do with creating
it. But I'm not sure. Maybe I'm a list dreaming that I was a person?
I thought this was the OSM-developers list.
Yes,
On Feb 12, 2008 2:23 AM, Frederik Ramm [EMAIL PROTECTED] wrote:
BTW, does having UTF8 keys mean that a key may contain a null byte, or
is UTF8 crafted in a way to avoid that?
It's specially crafted so that:
- A NUL byte can't appear in any valid charater
- No character is a substring of any
(blackadder) [EMAIL PROTECTED]:
Stefan Keller wrote:
Sent: 12 February 2008 12:36 AM
To: dev@openstreetmap.org
Subject: [OSM-dev] Restrict key names on order to retain reusability of
OSM
Hi all,
I just have finished a converter of OSM xml format to GML and I BOLDLY
suggest to constrain
Stefan Keller skrev:
You are right that XML names (= keys/tags) are valid in unicode
in which case the encoding of the whole XML document (exchange file)
must support this.
But you know well that many tools have problems with non-ASCII XML
element and attribute names (for content/value
Marcus Wolschon wrote:
Stefan Keller schrieb:
| BTW: Restrincting tags in del.icio.us http://del.icio.us to ASCII did
| not restrain the success of social bookmarking in any way IMHO.
Well, it did. There are localized sites like that that allow
any utf8-characters and they are used.
2008/2/12 Stefan Keller [EMAIL PROTECTED]:
GML/XML is *not* the issue, you know that:
It's almost any application outside OSM database.
It's about reusability and consistency!
I love the approach of key-value pairs (and I like beers too... ;-).
I agree with Martijn that before all, spaces
Stefan Keller wrote:
BTW: Restrincting tags in del.icio.us to ASCII did not restrain the success
of social bookmarking in any way IMHO.
And allowing \W tags in OSM has not restrained the success of Mapnik,
Osmarender, the cycle map, the Garmin .img files, Kosmos, or any of
the other
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stefan Keller schrieb:
| GML/XML is *not* the issue, you know that:
| It's almost any application outside OSM database.
| It's about reusability and consistency!
Dear Stefan,
I too strongly oppose to restrict the character-set.
If you want
Frederik Ramm skrev:
Hi,
I just have finished a converter of OSM xml format to GML and I
*BOLDLY*suggest to constrain the allowed characters of tags (=
key-names) to the
following XML related set:
'aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTuUvVwWxXyYzZ_' in order to retain
reusability.
Stefan Keller skrev:
Hi all,
I just have finished a converter of OSM xml format to GML and I
*BOLDLY*suggest to constrain the allowed characters of tags (=
key-names) to the
following XML related set:
'aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTuUvVwWxXyYzZ_' in order to retain
reusability.
Hi all,
I just have finished a converter of OSM xml format to GML and I
*BOLDLY*suggest to constrain the allowed characters of tags (=
key-names) to the
following XML related set:
'aAbBcCdDeEfFgGhHiIjJkKlLmMnNoOpPqQrRsStTuUvVwWxXyYzZ_' in order to retain
reusability.
After having looked at more
25 matches
Mail list logo
