Code not work - DESPERATE HELP :(

[fx5900]

Hi,

i am trying to convert an .osm (openstreetmap) file into gml format and
finally to shapefile given this wiki info
http://wiki.openstreetmap.org/index.php/GML. I'm using windows and when i
entered the following commands osm2gml.py < map_01_data.osm >
map_01_data.gml on my dos prompt i get a number of errors, some of which
are bellow:

Traceback <most recent call last>:
File "C:\osm2gml.py, line 86, in <module>
xml.sax.parse <sys.stdin, osmParser >
IOError : [Errono 9] bad discriptor

i did manage to convert it to gml format but was clearly unsuccesful because
of the error and it was 1kb.
Another point i would like to add is that ran the file using PythonWin
(ActiveState) with map_01_data.osm as the argument and after hitting ok,
then cancel i got

Traceback (most recent call last):
File
"C:\Python25\Lib\site-packages\pythonwin\pywin\framework\scriptutils.py",
line 310, in RunScript
exec codeObject in __main__.__dict__
File "C:\osm2gml.py", line 86, in <module>
xml.sax.parse( sys.stdin, osmParser )
File "C:\Python25\lib\xml\sax\__init__.py", line 33, in parse
parser.parse(source)
File "C:\Python25\lib\xml\sax\expatreader.py", line 107, in parse
xmlreader.IncrementalParser.parse(self, source)
File "C:\Python25\lib\xml\sax\xmlreader.py", line 123, in parse
self.feed(buffer)
File "C:\Python25\lib\xml\sax\expatreader.py", line 211, in feed
self._err_handler.fatalError(exc)
File "C:\Python25\lib\xml\sax\handler.py", line 38, in fatalError
raise exception
SAXParseException: <stdin>:1:0: syntax error

Please would somebody mind telling how i can covert my osm file into the
..gml format using the python file on the dos command or using pythonwin.

Cheers

 

[Bill McClain]

Hi,

i am trying to convert an .osm (openstreetmap) file into gml format and
finally to shapefile given this wiki info
http://wiki.openstreetmap.org/index.php/GML. I'm using windows and when i
entered the following commands osm2gml.py < map_01_data.osm >
map_01_data.gml on my dos prompt i get a number of errors, some of which
are bellow:

Does this give any better results:

python osm2gml.py < map_01_data.osm > map_01_data.gml

-Bill

 

[fx5900]

Hi,

I just went to go and get a coffee when i noticed a email, thought it was
just usual spam. Read your message, and it worked. it was because i did not
put they 'python' keyword infront. How did u figure it out?

Although, cos i nver worked with python, things are bound to go wrong on the
first hurdles right?

Cheers

 

[Bill McClain]

I just went to go and get a coffee when i noticed a email, thought it was
just usual spam. Read your message, and it worked. it was because i did not
put they 'python' keyword infront. How did u figure it out?

It is some problem with the DOS box on Windows. I believe the standard input
and output get lost somehow. I just encountered it myself. Using the "python"
command is not required on other platforms--Linux, for example.

If anyone has a more elegant solution I would like to hear it. I hate
documenting "this way on Windows, another way everywhere else..."

-Bill

 

[Glenn Linderman]

It is some problem with the DOS box on Windows. I believe the standard input
and output get lost somehow. I just encountered it myself. Using the "python"
command is not required on other platforms--Linux, for example.

If anyone has a more elegant solution I would like to hear it. I hate
documenting "this way on Windows, another way everywhere else..."

-Bill

The problem with stdin/stdout is on Windows 2000 (and maybe the earlier
NT?). But not on XP or AFAIK Vista.

It only occurs when a program is executed indirectly using the file
associations instead of directly via the command line.

File associations, are the Windows "let's do it a different way"
alternative for Unix she-bang lines (#!/path/to/python).

 

[Bill McClain]

The problem with stdin/stdout is on Windows 2000 (and maybe the earlier
NT?). But not on XP or AFAIK Vista.

It only occurs when a program is executed indirectly using the file
associations instead of directly via the command line.

File associations, are the Windows "let's do it a different way"
alternative for Unix she-bang lines (#!/path/to/python).

Can you elaborate on this? I have some very simple command-line utilities I
would like to make available on different platforms, but what little I knew
about Windows is fading into the past.

This example:

import sys
print sys.stdin.read()

....works in the Windows XP dos box if I do:

python demo.py < file.txt

....but I get the error 9 for:

demo.py < file.txt

Is there any way to make the second version work on Windows?

-Bill

 

[Tim Golden]

Can you elaborate on this? I have some very simple command-line utilities I
would like to make available on different platforms, but what little I knew
about Windows is fading into the past.

This example:

import sys
print sys.stdin.read()

...works in the Windows XP dos box if I do:

python demo.py < file.txt

...but I get the error 9 for:

demo.py < file.txt

Is there any way to make the second version work on Windows?

You've got a few options. Perhaps the simplest is to use something
like the effbots exemaker [1] which creates a stub for your script
but which is an .exe to the redirection should work. The user has
to have Python installed on the system (it's not a py2exe lookalike)
but it can make things like this simpler.

I believe -- but I've never really gone into this -- that the
setuptools extensions to distutils offer a way to do this as
part of the installation, so if you were having the scripts
installed via a setup.py (or setup.whetever) then that might
be the way.

Obviously py2exe (also a distutils extension) is another
possibility, altho' I would see it here as a fallback option
since it's a bit more heavyweight.

This is the MS article which describes the problem:

http://support.microsoft.com/kb/321788

and suggests that it's fixed in XP SP1 but this
thread:

http://mail.python.org/pipermail/python-list/2008-September/506466.html

suggests that maybe it's not.

TJG

 

[Stef Mientki]

Ok, thanks!

It is a small hobbyist community. I'll just document it and tell them "life is
hard for Windows users."

Well I don't know any Windows users that still use DOS-boxes ;-)
cheers,
Stef

 

[Bill McClain]

Well I don't know any Windows users that still use DOS-boxes ;-)
cheers,

What do they do when they want to run a cross-platform command-line script
with parameters and redirection?

I suppose they could install cygwin and run bash, but that seems like overkill
for what should be a simple task.

-Bill

 

[Tim Golden]

What do they do when they want to run a cross-platform command-line script
with parameters and redirection?

I think it's a slight dig at the nomenclature. Technically,
Windows from NT onwards has had Consoles. (At least, I think
that's what they're called). But lots of people still say
"DOS box" from back in the day.

Architecturally speaking, Windows 3.x (and below) sat on top
of DOS. The Windows NT family was an OS unto itself pretty
much, and provided a Console which sat on top of it.

TJG

 

[Shawn Milochik]

What do they do when they want to run a cross-platform command-line script
with parameters and redirection?

I suppose they could install cygwin and run bash, but that seems like overkill
for what should be a simple task.

Easy. Make a desktop shortcut which includes the parameters, etc.
People do that all the time, including for GUI apps such as Internet
Explorer which have some optional command-line shortcuts.

The only thing you have to do is make sure that the Windows machine
associates files with the .py extensions with the Python interpreter.
The easiest way is to right-click a .py file, select "Choose an
Application," select the Python runtime, and check the box for "always
use this program.

 

[Glenn Linderman]

Can you elaborate on this?

What I reported is what I remembered from when XP came out. Seems like

Testing now indicates that it doesn't work so well on XP at this point.

That either means that my memory was faulty, or that some XP update
broke it again.

What I remember for sure, is that this is not a new problem; that it was
introduced in some version of Windows, that it was fixed in some later
version of Windows. The whole issue totally predates Vista, so it would
have had to have been the introduction of 2000 or XP that fixed it. Or
a service pack.

Here is what Google helped me find that M$ remembers:
http://support.microsoft.com/kb/321788 (Ah, I see Tim found this too)

Looks like it was broken in both 2000 and XP, and fix in both via a
service pack or hot fix, but seems to now be broken again?

Creating the registry setting mentioned in this kb article didn't
(immediately) solve the problem. Next time I reboot, I'll try to
remember to test this again.

 

[Bill McClain]

Easy. Make a desktop shortcut which includes the parameters, etc.
People do that all the time, including for GUI apps such as Internet
Explorer which have some optional command-line shortcuts.

The only thing you have to do is make sure that the Windows machine
associates files with the .py extensions with the Python interpreter.
The easiest way is to right-click a .py file, select "Choose an
Application," select the Python runtime, and check the box for "always
use this program.

Ok, trying that...works, but the window doesn't stay open, so we can't see the
results. Any way to do that? Sorry for the Windows-101 tutorial.

DOS box vs Console: I'm sure they use the same icon...

-Bill

 

[Glenn Linderman]

Creating the registry setting mentioned in this kb article didn't
(immediately) solve the problem. Next time I reboot, I'll try to
remember to test this again.

It occurred to me to create a new CMD Prompt (yes, it is not a "DOS box"
in these versions of Windows) after creating the InheritConsoleHandles
registry value, and it works then.

XP, latest patches.

The old CMD Prompt still fails.

 

[Bill McClain]

Ok, trying that...works, but the window doesn't stay open, so we can't see the
results. Any way to do that? Sorry for the Windows-101 tutorial.

I received an email solution: prepend the shortcut command with "cmd.exe
/k". Works great!

-Bill

 

[Glenn Linderman]

A tad confusing -- do you mean the previous console window is
misbehaving, but creating a new console window is working? That behavior
I can believe, as the console probably read the relevant registry
entries on start-up, hence did not see any changes (same thing occurs if
you edit environment variables using My Computer/Properties).

Correct. Creating a new CMD window after making the registry
modification worked, while the CMD window created before the registry
modification continued to fail.

But be careful otherwise... WinXP still has command.com

Microsoft(R) Windows DOS
(C)Copyright Microsoft Corp 1990-2001.

C:\DOCUME~1\DENNIS~1>

besides the more modern cmd.exe

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\Dennis Lee Bieber>

So "old CMD Prompt" could be mistaken to refer to the ancient
command.com <G>

Indeed it does, and could, but that isn't what I meant. I didn't test
at all with command.com.

 

[Thorsten Kampe]

* Tim Golden (Fri, 31 Oct 2008 12:21:12 +0000)

This is the MS article which describes the problem:

http://support.microsoft.com/kb/321788

and suggests that it's fixed in XP SP1 but this
thread:

http://mail.python.org/pipermail/python-list/2008-September/506466.html

suggests that maybe it's not.

That article mentions a pipe - and has nothing to do with input or
output redirection...

Thorsten

 

[Thorsten Kampe]

* Dennis Lee Bieber (Sat, 01 Nov 2008 11:34:32 -0700)

And what is a pipe, at least on Windows command lines, if not a
linked pair of I/O redirection? First program output redirected to <>,
second program input redirected from <> (where <> represents some
shared data stream which could possibly be implemented by creating a
scratch file in, say %TEMP%\apipe.dat)

In the case of redirection you get the input from or output to a file.
In the case of a pipe you don't have files involved.

Thorsten

 

[Lie Ryan]

Well I don't know any Windows users that still use DOS-boxes ;-) cheers,
Stef

Well, that is because newer Windows version (NT-family) no longer have
DOS boxes. The "black window" in NT-family Windows are command prompt and
is different from a real DOS box in previous Windows (non-NT-family).
Anyway, I do use command prompts quite regularly, usually for simple
"ping"s and other simple commands like "chkdsk", "defrag", "attrib", etc.
Yes, I do know that each of these have GUI-equivalents.